DEV Community

Cover image for We Are Switching From TestCafe to CodeceptJS – Here’s Why
Paweł Kowalski for platformOS

Posted on • Updated on • Originally published at platformos.com

We Are Switching From TestCafe to CodeceptJS – Here’s Why

We have been using and promoting TestCafe at platformOS for the past couple of years with great success. Because a lot of people will write tests and maintain them over a long time, an End-to-End framework has to come with some specific requirements:

  1. Easy to remember and type out API
  2. Good waiting mechanisms (for XHR requests, animations)
  3. Extendibility, page object support, helpers support
  4. Good search in documentation to quickly reference less used APIs
  5. Run properly in Docker and/or GitHub Actions

TestCafe is scoring high on the above areas, I would say averaging around 7.5/10, which means there is still room for improvement.

Even though we have been happy with TestCafe, last year when I stumbled upon a new contender, CodeceptJS, I decided to give it a shot on our documentation and marketing sites. It delivered excellent developer performance. It was enough to dive deeper into its documentation and expand our test suites to include some more test cases.

1. Test API

Very often when writing TestCafe tests, we had to resort to vanilla JS and DOM operations. One of the most frustrating examples was to get some text from an element and then compare it to another. It was too much work and I never could see a reason why TestCafe had no API for that. CodeceptJS has a lot more API helpers to avoid these complications and diverging into vanilla JS. Below, I give you some examples of TestCafe scenarios converted to CodeceptJS ones.

Checking if correct breadcrumbs links are present on a page

// TestCafe
test('Breadcrumbs are showing up', async t => {
  await t.navigateTo('/api-reference/liquid/introduction');

  await t.expect(Selector('.breadcrumbs a').withText('Documentation').exists).ok();
  await t.expect(Selector('.breadcrumbs a').withText('API Reference').exists).ok();
  await t.expect(Selector('.breadcrumbs a').withText('Introduction').exists).ok();
});

// CodeceptJS
Scenario('Are showing up', ({ I }) => {
  I.amOnPage('/api-reference/liquid/introduction');

  I.see('Documentation', '.breadcrumbs');
  I.see('API Reference', '.breadcrumbs');
  I.see('Introduction', '.breadcrumbs');
});
Enter fullscreen mode Exit fullscreen mode

If this is interesting to you read rest of this article on our blog.

Read more

If you are interested in more performance oriented content, follow me and I promise to deliver original, or at least effective methods of improving your website.

Top comments (1)

Collapse
 
leob profile image
leob • Edited

I've used TestCafe as well, and while it was okay and seemed a step up from previous Selenium based tools, I always had the idea that it could be better. Debugging was still hard, tests were still flaky, and so on.

Now when working with Laravel I've finally found that holy grail I was looking for - with Laravel's browser testing framework (it's called Laravel Dusk), you write your browser tests in PHP. Programming it is a breeze, debugging is 10 times easier, tests run stably and reliably, it's a breath of fresh air.