Great video! One area that i've faced, Is that 'timezoneId' override the brower's time zone, but not NodeJS's timezone, so if I do assert by using the Date API inside NodeJS, it will be still the machine UTC timezone ,therefore I do 'process.env.TZ=' at the start of the test, so both NodeJS and the Browser will be at the same timezone
TIL! This is a great call which would have been worth highlighting. 😅 But thank you! I published a follow-up TIL post on my own blog: www.stefanjudis.com/today-i-learned/set-the-default-time-zone-in-node-js/ 🫣
Wonderful example. Just curious to know can we use this clock for 30 mins wait scenario? In my case, after approving we need to wait for 30 mins to reflect in Ui.
Thanks and great question. I guess it depends on the implementation of your UI. If the 30 mins wait scenario is done in the browser that should work because you can overwrite it with Playwright. But if the front end asks a server if the 30 mins are over, I doubt it will work. Hope this helps.
@@ChecklyHQ I was wondering about the best way to validate an API by comparing the entire response body with a predefined response, like using a JSON schema, for example. Do you think this is an effective approach to API validation? If so, how would you structure these tests in your project? If not, what alternative approach would you recommend? Any tips you can offer are greatly appreciated. Thank you for your attention!
Thanks! That's a very interesting question and I have to give this more thoughts. But here's my first reaction. I just looked at some swagger files / JSON API schemas and while I like the idea of automatically testing the predefined API endpoints and responses, I wonder if that's done easily in practice. I mean, testing a RESTful API is quickly done. POST -> PUT -> GET -> DELETE the resource, right? In this example I know what I want to create and what I expect to come back. It's an entirely manual process. But I'm in charge. If I now take an API schema defintion (or swagger or whatever) I get some information about how the API works but probably not enough to test cover the API because I still have to define the test data and the cases. Are there tools that parse a schema and create necessary test data on the fly? I don't know. But without such tool, testing complex cases feels like a mixed bag of automation and manual maintance and this wouldn't feel great. Looking forward to hearing your thoughts! 🦝
@@ChecklyHQ No doubt, it depends a lot on each situation, but you are right, without enough information it’s not a good strategy. However, knowing the API well, it can be a good approach. Thank you, Stefan!
cool example, clear as always! thanks for sharing.
Thanks for following along!
Great video... thanks for sharing... :)
Thanks for watching!
Great content as always!
Thank you for covering new Playwright features!
Thanks for following along! 🦝
Great video!
One area that i've faced, Is that 'timezoneId' override the brower's time zone, but not NodeJS's timezone, so if I do assert by using the Date API inside NodeJS, it will be still the machine UTC timezone ,therefore I do 'process.env.TZ=' at the start of the test, so both NodeJS and the Browser will be at the same timezone
TIL! This is a great call which would have been worth highlighting. 😅 But thank you! I published a follow-up TIL post on my own blog: www.stefanjudis.com/today-i-learned/set-the-default-time-zone-in-node-js/ 🫣
Amazing tool, amazing video!
Thanks! 🦝
awesome
Wonderful example. Just curious to know can we use this clock for 30 mins wait scenario? In my case, after approving we need to wait for 30 mins to reflect in Ui.
Thanks and great question. I guess it depends on the implementation of your UI. If the 30 mins wait scenario is done in the browser that should work because you can overwrite it with Playwright. But if the front end asks a server if the 30 mins are over, I doubt it will work.
Hope this helps.
Hey Stefan, could you please bring more content about API testing in playwright ? Vielen Dank mein Freund
Sure thing, do you have any ideas what would be helpful for you and the community?
@@ChecklyHQ I was wondering about the best way to validate an API by comparing the entire response body with a predefined response, like using a JSON schema, for example. Do you think this is an effective approach to API validation? If so, how would you structure these tests in your project? If not, what alternative approach would you recommend? Any tips you can offer are greatly appreciated. Thank you for your attention!
Thanks! That's a very interesting question and I have to give this more thoughts. But here's my first reaction.
I just looked at some swagger files / JSON API schemas and while I like the idea of automatically testing the predefined API endpoints and responses, I wonder if that's done easily in practice.
I mean, testing a RESTful API is quickly done. POST -> PUT -> GET -> DELETE the resource, right? In this example I know what I want to create and what I expect to come back. It's an entirely manual process. But I'm in charge.
If I now take an API schema defintion (or swagger or whatever) I get some information about how the API works but probably not enough to test cover the API because I still have to define the test data and the cases.
Are there tools that parse a schema and create necessary test data on the fly? I don't know. But without such tool, testing complex cases feels like a mixed bag of automation and manual maintance and this wouldn't feel great.
Looking forward to hearing your thoughts! 🦝
@@ChecklyHQ No doubt, it depends a lot on each situation, but you are right, without enough information it’s not a good strategy. However, knowing the API well, it can be a good approach. Thank you, Stefan!