Testcafe: Add capability to set cookie (httponly and client-side)

[rob4629]

What is your Test Scenario?

We have a number of test scenarios that require deleting (expiring) cookies, both client side and server side (httponly: true). Right now, we can use a Client Function to manipulate the client side cookies... but are unable to interact with the server side (httponly) cookies.

What are you suggesting?

I believe it would be really useful to have inbuilt cookie functions, which allow for interaction with both client and server side cookies. This allows for chanining:

await t
      .navigateTo('/<url>')
      .setCookie('mySessionCookie')
      .click(<button>)
      .expect(<thing>);

await t
      .navigateTo('/<url>')
      .deleteCookie('mySessionCookie')
      .click(<button>)
      .expect(<some-other-thing>);

It would also hopefully limit the number of <_search engine of choice_> searches for "TestCafe get/set/delete cookies", and trying to find a solution that suits the user's scenario.

What alternatives have you considered?

I've used the recommended solution with a Client Function, however this doesn't solve my problem of interacting with server side (httponly) cookies.

Additional context

Other frameworks have this functionality: Cypress, Puppeteer, Nightwatch (selenium based) etc. All of which allow for client and server side interaction with cookies.

[miherlosev]

Hi @rob4629

Thank you for your suggestion. I agree with you that in some cases it would be useful to have a method to set cookies.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Example

await t.setCookie({
    key: 'test-key',
    value: 'test-value',
    domain: '.my-domain.com',
    secure: true    
})

[juliuszfedyk]

When using the ClientFunction method I have to force navigation on every single tests after the page is loaded by fixture and cookies are set, so its a lot of unnecessary page loads - makes it terrible for a bigger test suit.

I would suggest setting default cookies in the fixture:

fixture`Search Page`.page(testUrl).cookies([{
    key: 'test-key',
    value: 'test-value',
    domain: '.my-domain.com',
    secure: true    
}]);

I don't know if that would be possible using testcafe's stack though.

For server side cookies you can try solution by Rafaela Azevedo. I just think she made a small mistake and the header name should be "Cookie" and not the name of the cookie (as explained here).

It would be nice to have more control over browser cookies. My app for example has a gpdr banner, and this is an roadblock for using TestCafe. In this case I will have to switch to nightwatch ( glad to hear it covers cookies ) which is too bad since I really like testcafe's clarity.

[rob4629]

I would suggest setting default cookies in the fixture

I think it's difficult to have a "One size fits all" solution to this. While that will be useful in most cases, it wouldn't in mine as I need to delete/amend cookies mid-test for some scenarios.

Definitely something to keep in mind though, since implementing a function on the test object would require setting cookies in the BeforeEach hook...

[saropatzi]

re-iterating on the Cookies, since many personalization options relies on them.
It would be useful to keep cookies while using navigateTo, or at least have an option to keep them including the httpOnly ones.

Actually I am struggling on a test case that has a different behavior if the user has an httpOnly cookie set or not.
The cookie is set the first time the user land on the site.
It activates a redirection for a specific page the second time, but don't know why on Testcafe this is not happening.
I am using navigateTo to keep everything in the same test and tried userRole hoping it could help.
But did not :_(

[miherlosev]

Hi @saropatzi

The site with TestCafe should work in the same way as without TestCafe. If you found any differences, please create a separate issue with an example illustrating it.