TestCafe & CucumberJS

You could run TestCafe on it's own without any additional JavaScript libraries, but I believe there are two big reasons to integrate TestCafe and CucumberJS.

Scaling your tests

When you have a small amount of tests it's easier to manage, but as your test count starts to grow it might start getting unwieldy to manage. Also, there are probably steps and selectors that you are going to use for multiple tests. Now you could manage those with separate functions that encapsulate the step, but I think the cucumber framework makes the integration more transparent.

(You are perfectly fine to disagree with this, and if you are looking for a lighter alternative to this repo check out gherkin-testcafe.)

Business Readable

Another advantage to using Cucumber is it's ability to understood by the non-technical stakeholders. Take the example from our previous exercises.

test('First test - Form Submission', async function (t) {
    const nameField = Selector('#g2599-name');
    const emailField = Selector('[name="g2599-email"]');
    const submitButton = Selector('input.pushbutton-wide');
    const experienceSelect = Selector('#g2599-experienceinyears');
    const experienceOption = experienceSelect.find('option');
    const commentBox = Selector('#contact-form-comment-g2599-comment');
    const contactFormSubmit = Selector('.contact-form-submission')
    const sentConfirmation = Selector('#contact-form-2599').child('h3')

    await t
        .navigateTo('http://www.globalsqa.com/samplepagetest/')
        .typeText(nameField, 'John Doe')
        .typeText(emailField, 'johndoe@gmail.com')
        .typeText(commentBox, 'This is a comment John Doe')
        .click(experienceSelect)
        .click(experienceOption.withText('5-7'))
        .click(submitButton)
        .expect(contactFormSubmit.child('p').innerText).contains('John Doe')
        .expect(contactFormSubmit.child('p').nth(1).innerText).contains('johndoe@gmail.com')
        .expect(sentConfirmation.innerText).contains('Message Sent')
});

Since you're familiar with the TestCafe you can parse through the code and figure out what's going on. If you were to give this test to a non-technical stakeholder would they understand what's going on? Probably not. Cucumber tries to bridge the gap between the technical team and the non-technical team, so everyone understands what work is being done. Let's rewrite the test above in a way that would be seen in a .feature file.

This is something you could hand off to anyone and they would probably have some idea about what's going on the in the tests.

Also, notice that the first scenario is process-driven meaning very verbose with each step whereas the second scenario is more business driven meaning more direct to the business need. You'll make your own decisions on how to write your tests just showing you two examples.