![]() You'll know when Visual Studio Code is in debugging mode when the status bar changes color (yellow, in this theme's case) and by the presence of additional debugging icons at the top of your code. Your test will launch as usual, and when it lands on a breakpoint, the test execution halts and Visual Studio Code enters debugging mode. You can run the test by clicking on the "Launch test files with TestCafe" option that appears on the status bar at the bottom, or by pressing the F5 key. You can now use Visual Studio Code to execute the current test file using TestCafe in debug mode. The red dot next to the line number indicates a breakpoint. You can also toggle breakpoints with your mouse by clicking on the left side of any line number of your code. You can toggle a breakpoint by pressing the F9 key on any line of code where you place your cursor in a test file. With your debugging configuration ready to use, all that's left is to set at least one breakpoint in your tests. It appears in the Run section on the left-hand side of Visual Studio Code, as well as the status bar at the bottom of the editor. Saving the configuration in launch.json adds the option to run your test files using TestCafe. For instance, change firefox to chrome if you're going to run your tests in Chrome. You shouldn't need to update anything here, although you may want to change the browser specified in the args attribute. The TestCafe documentation has an excellent in-depth explanation for each of these options. Test("User can log in to their account", async t => /node_modules/testcafe/bin/testcafe.js", You can place a breakpoint after the login form gets submitted like this: import loginPageModel from "./page_models/login_page_model" As an example, say you want to debug the login test from the "How to Get Started with TestCafe" article on Dev Tester. You can add breakpoints in TestCafe (and any Node.js application or script) with the debugger keyword. The next step you should do is to open your test and place breakpoints where you want the test execution to halt. The debugger process immediately pauses the test execution, so you won't see anything happening yet. By adding the -inspect-brk flag when running your tests, TestCafe starts the Inspector debugging process on a local port in your system (127.0.0.1:9229 by default). TestCafe has a command-line flag that allows you to kick-start the debugging tool from Node.js for your test suite. From there, you can check out different aspects of the code, like assigned variables and their values, function definitions, and more. ![]() This tool is a Node.js process that allows a debugging client to connect and see the insides of your application or script. TestCafe is a tool built on Node.js, which has a powerful built-in debugger known as Inspector. Debugging tests using the Chrome and Edge Developer Tools But these ways of debugging tests can provide lots of insight into slow and flaky tests, so it's a helpful technique to have in your toolbox. Most people will probably never need to use these methods. These methods are a bit more advanced and require some setup before you wield their power. This week, we'll discuss two more ways to debug your TestCafe tests. TestCafe has a few more debugging techniques to let you get deeper into the state of your tests. The three methods we talked about last week - taking screenshots and video, slowing down test execution, and pausing tests for further exploration on the browser - aren't the only debugging tricks TestCafe has under its sleeve. There's little to no setup for all of these methods. They're especially useful since the techniques explored in the previous article come included with TestCafe out of the box. These debugging methods can help you get to the bottom of why a test fails when you least expect it to fail. Last week on Dev Tester, we covered three useful ways to debug your TestCafe tests.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |