Hi there,
is it possible to control a (headless) browser as easily as I can do it with cypress during a full-app test? The topics I found about full-app mode are more than 3 years old…
Why not use Cypress?
It seems easier to access server-side code using full-app test. E.g. I’d like to insert 3 documents on the server, wait for a collection-hook to finish its job, then visit a route on the client, type something into an input and expect to see the documents in the result page.
Right, why not do that with Cypress? We do all of our e2e tests this way.
Ok, I’m clearly missing something 
How do you call server-side code from a cypress test? Let’s say I have an EventEmitter on the server and I want to listen to a particular event (because it signals when something finishes which I started from the browser). How can I do that from a cypress test?
With Cypress, you aren’t unit testing the code per-say or even listening for events. You are using the website like a user would and then checking the results (just programmatically). So you would write your Cypress code, to click here, do this or that, then check to see if the expected result happened. If the thing you’re trying to add to the db enters correctly, you’ll be able to see that taking place via the front end with Cypress. Otherwise you might be looking at the wrong tools. Cypress and Puppeteer and other full app testing things are for using the app like a user would programmatically.
If you are looking to just test that server side code in a more integration or unit way, I would just go straight to something like Jest.
2 Likes
I think the missing piece here may be that you need to actually run the app separately, and tell cypress to go to that address. We start up the server on say, localhost:300, then on the first line of our test, tell cy to go to that address, then click around to do the testing.
Inserting to database and listening to events on the server is not what an E2E/cypress test is for, they are meant to be from the perspective of the user, who interacts with your app though the browser. So you would click on the buttons on the front end, and hopefully see that the app responds correctly.
A “full-app-test” on the other hand, is a bit different. There you are starting up the full app, but still doing unit-tests from the perspective of the server, not interacting with a browser. Personally, I have had little use for this. I have only used unit tests that only import the necessary bits to get each of them to work, and done full E2E tests to test the user journey and features as a whole.
1 Like
My idea was no to isolate the client and the server since they’re working together in the end. E.g. when a user clicks on the “rocket launch” button, I expect the rocket to be launched and not just a confirmation in the browser. Sure I can test the server side that given the right inputs it launches a rocket and test the client side that it gives the right inputs to the server, but aren’t the “right inputs” just implementation details? All I care about are the button and the rocket.
Anyway, I found this: https://github.com/vazco/meteor-universe-e2e
With this I can control a browser from server tests and simply switch between server and client contexts.