Working on a layout is not easy when there are too many possibilities and it gets more complicated if it's related to mouse direction. It's not just up and down, you literally need to test all horizontal and vertical possibilities. Imagine you also study elements getting effected by mouse movement, where things getting harder and harder.
In the nutshell, I am a hard unit-test believer, but in this case, you definitely need to do testing and not a unit test we are talking here about an end-to-end test where you see elements moving virtually and experience each case individually.
The big question is how you do it, taking into consideration that your project already uses a unit test with Jest.
Puppeteer it
The wise decision in my case is to use, Puppeteer. You integrate Puppeteer with Jest in jest.integration.config.js
a whole new config and start writing your first integration test.
{ "preset": "jest-puppeteer" }
Everything is async
in Puppeteer so you go by something like this to get your element:
const element = await page.waitForSelector("#id-something");
I need to get element box size so I added:
const elmBox = await element.boundingBox(); const {x, y, width, height} = elmBox // do something here...
You immediately start to notice that's Puppeteer is natural. I am not learning something new, it's easy to use and you supposedly can go further. Let's try mouse events.
// move the mouse to new coordinates await page.mouse.move(100, 200); // triggers mouse down await page.mouse.down(); // move the mouse to new horizontal position await page.mouse.move(500, 200); // triggers mouse up await page.mouse.up();
Very easy. Very handy. Except there's a configuration related. you can't keep the browser open , there's no time travel, and you can't repeat the test cases individually. So, if you test and develop by doing TDD it's nearly impossible to actually see what's going on. You can slow down the test but if you running a server and you wait to browser to re-launch that's means waiting for infinity.
launch: { devtools: true, slowMo: 500, },
Even with Puppeteer reaching version 5 there's a gap in its ecosystem. Because it's not a testing framework.
Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol.
Trying Cypress
The first issue with Cypress, that you need to start from scratch. A new assertion, a new testing framework, with a new structure.
The installation includes examples that really help to know where you are going and what your test cases should look like. You use a chain of commands. You get something, trigger it, test it.
cy.get("#id-something").then((elm) => { elmBox = elm[0].getBoundingClientRect(); const {x, y, width, height} = elmBox });
Cypress uses trigger
to trigger an event
cy.get("#id-something") .trigger("mousedown", { button: 0 }) .trigger("mousemove", { clientX: 100, clientY: 200 });
It uses a whole different approach but once you read it you easily get it. Until you start to use assertion.
This is from Cypress documentation:
cy.get('.error').should('be.empty') cy.contains('Login').should('be.visible') cy.wrap({ foo: 'bar' }).its('foo').should('eq', 'bar')
You take a deep breath and ask yourself, should I really have to learn this? Even something like beforeAll
in cypress is before
. So, you get the sense that whatever transition you make it's not going to be smooth as you expect.
But your test runs with zero-config, with time travel, and yes you can repeat it forever. And it's super-fast.
However, my problem is not with speediness. I need, at a certain point to be able to repeat the same test command.
It turns out, Cypress automatically takes a screenshot for every command and you simply can highlight it forever which means a totally new debugging experience.
Conclusion
When it comes to increasing productivity, end-to-end test can be the real solution. Forget about all articles tell you about the benefits of testing and why you should use e2e. I personally experienced a huge difference in fixing bugs saving hours of chasing needles in a haystack.
Puppeteer can be a solution for expanding your test cases. But if you are using it with development, the answer is Cypress.
Cypress is rich with examples, and supported community. It's designed for the end-to-end tests; therefore, you won't struggle using it. If you are familiar with Mocha it won't take you a long time to get familiar with assertation. And it's amazing how you can use it even with no previous background about this type of testing. Most importantly, you immediately start experiencing the benefits of each test you write instead of figuring out how to configure it with your project.
以上所述就是小编给大家介绍的《To Puppeteer, or to Cypress》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。