I have an AngularJS application and I'm trying to use Cypress to stub some of the network requests that it makes. Currently, my problem is with a request with resource type Img. I know from Cypress documentation that Cypress cannot stub non-XHR resource types/requests, but I'm looking for a workaround.
My application requests the image from a backend server, which I want to stub or fake. I prefer not to modify the application code, and would rather create an external workaround.
I've looked into the following and found them not to be useful in this scenario:
Sinon.js - Similarly can only handle XHR requests.
nock - Replaces node's http.request, but that doesn't seem to work within Cypress. It might work if I added it straight into my application code, which I prefer not to do.
I've also tried the following but was unsuccessful:
mockserver - Ran the mockserver and added an expectation, but none of the requests made to the mockserver seemed to go through.
Service Worker API - Was unsure about how to register my service worker, since it requires a .js file as an input. What .js file would be served as input if I'm controlling the service worker via Cypress?
a mock server using express - The issue is the application is running on localhost:<some_port>, while the mock server is running on localhost:<some_other_port>. I'm having trouble specifying port numbers when constructing the request through the application. Basically, my application isn't really respecting different port numbers.
EDIT:
I've been successful with creating a mock server using express. According to Cypress documentation, servers shouldn't be started and stopped within before() and after()'s. Instead, they should be started prior to Cypress being started, and stopped after Cypress is stopped.
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.
Running Laravel 7 with the job queue using the 'database' driver.
There is a call from the frontend to an API that dispatches a job and immediately returns a response with the status (queued). This works fine when called from the frontend Javascript.
Trying to test this same endpoint with PHPUnit, with a test that calls the same API endpoint, I see that the job appears to be dispatched in sync mode, i.e. the HTTP response does not arrive until the job has completed, because the ->dispatch() method does not return until then.
Both tests are using exactly the same dev environment - one runs async, the other sync.
Can't see anything in the docs about this. How to make the job get queued asynchronously when running with PHPUnit, so we can test the intended behavior?
You can always override .env configurations in the phpunit.xml file.
<server name="QUEUE_CONNECTION" value="a_different_connection"/>
I personally prefer to use the sync connection in my test suite, to make sure everything works correctly.
You can also use Queue::fake(), which is mentioned in the above comment.
I have a bunch of HTML5 canvas tests in my library which I run via Karma and Jasmine. If I detect differences in my tests I show the canvas DOM elements with my generated image output and a diff on the browser page. But when I run my tests in Chrome Headless and/or on my CI environment I have no way of checking the test results in case they fail. And that's currently the issue I'm facing: when I run the tests with a UI, they are green, if I run them in Chrome Headless they fail but I have no chance of checking my visual output.
As solution I'd like to write my generated images to disk. On local tests I can then check this folder what happened an on CI I can publish the result images as artifacts. But here comes the point: Karma and Jasmine seem to have no proper mechanism in place for this task. Also I could not find any plugin tackling this challenge of properly accessing the local file-system from your tests.
A tricky aspect is also that I cannot use promise (async/await) operations at the place where I want to save files. I am within a Jasmine CustomMatcher which does not have promise support I could try rewriting my tests again to handle the error reporting to Jasmine.
My attempts so far:
I started with a custom Karma reporter listening to browser logs and potentially use this as channel to hand over the image bytes to Node for writing to disk. But this additional plugin registration messed with my overall Karma configuration. Karma and Rollup were not working anymore once I registered my custom reporter and I never found out if such large byte amounts can be even transferred via this channel.
Then I started with an API via karma-express-http-server where I "upload" the files to be saved. But I stopped half way as such a simple task seem to require again a bunch of libs and custom implementation to get a simple file upload running (karma-express-http-server, multer). Also I need to rely on synchronous Ajax calls here which is not really future proof.
The Native File System API heavily relies on Promises so I cannot use it.
There must be a simpler way of just writing a file as part of your tests to disk while when using Karma and Jasmine.
I am trying to use cypress for running some monitoring tests on production.I am also using snapshot match plugin to compare screenshots.
I just want to know is this safe to do ?
I am not using any dashboard services from cypress -just running tests on our local machines-will cypress sent any info outside our network?
Cypress doesn't send anything to Cypress's servers unless you specifically configure it to - it's safe.
The only other thing is, by default, Cypress will send crash reports (when Cypress itself crashes) to be analyzed. You can turn this off by following the instructions here.
Is it better to use mocha with a local server through the grunt-contrib-connect task or just run it with grunt-mocha?
What are the differences/downsides of both?
They are two totally different things. You do not automatically run spec files with grunt-contrib-connect, it is meant to be used in conjunction with other tasks that hit the connect server. You can use it with grunt-mocha (see the urls option), but it's really only useful if you need to test with server logic. Otherwise, you can mock server responses and XHR requests in your tests using sinon.