Right from the start, WebStorm poses me with 2 issues:ġ. I started to think of ways to integrate Jest debugging into Webstorm 9 which is the powerful IDE I am using. Since I am never a fan of command-based debugger, I got lost very easily with Node’s debugger. Run - Run script (automatically runs on debugger's start) Repl - Open debugger's repl for evaluation in debugging script's context Watchers - List all watchers and their values (automatically listed on each breakpoint) Unwatch(expr) - Remove expression from watch list Watch(expr) - Add expression to watch list
#JEST WEBSTORM DEBUG CODE#
List(5) - List scripts source code with 5 line context (5 lines before and after)
SetBreakpoint('script.js', 1), sb(.) - Set breakpoint on first line of script.jsĬlearBreakpoint, cb(.) - Clear breakpointīacktrace, bt - Print backtrace of current execution frame SetBreakpoint('fn()'), sb(.) - Set breakpoint on a first statement in functions body
SetBreakpoint(line), sb(line) - Set breakpoint on specific line SetBreakpoint(), sb() - Set breakpoint on current line Pause - Pause running code (like pause button in Developer Tools) Node debugger provided a set of useful commands We can key in “c” or “cont” to run until the breakpoint. This will insert a breakpoint at the first line of “myView-test.js”. Or we can put a breakpoint into our testĭebug> sb('C:\\example\\reactApp\\_tests_\\myView-test.js', 1) Once the debugger is started, we will see debugger paused at the first line of jest.cs. We can use Node Debugger’s supported APIs to step through the code. Partial path will work probably because Jest has converted into a RegEx. “myView-test.js” is the test file that we intend to debug. 'useful for debugging, but such use cases are pretty rare.'ĥ. 'a worker pool of child processes that run tests). 'Run all tests serially in the current process (rather than creating ' + The default behavior for Jest is that it will spawn multiple processes to run tests concurrently. Excerpt from description of this option in source code (.\node_modules\jest-cli\bin\jest.js): “–runInBand” tells Jest to run all tests in the current process instead of spawning child processes. This file is called when we use call “Jest” in “\node_modules\.bin”Ĥ. More information on harmony can be found here.ģ. “.\node_modules\jest-cli\bin\jest.js” is the entry point for Jest. This wrapper provides a set of commands we can use to step in / out / navigate through code which is missing in V8’s “node –debug”. (I agree that they look very similar)Ģ. “–hamony” flag is required for Jest to run properly. “debug” calls a wrapper for V8 engine’s debugger which can be started with “node –debug”. \node_modules\jest-cli\bin\jest.js -runInBand myView-test.jsġ. “node debug” will start the node debugger. To debug a Jest test, say “myView-test.js”, we need to run node with the command below: Node’s default debugger is entirely command-based which is similar to GDB – I am never a fan of command line debugger, but it get things done. Instead, we need to rely on the debugger that comes with Node / V8 engine.
This is different from Karma + Jasmine which leverage browsers to run tests. This causes one of the biggest drawbacks in Jest in my opinion: we cannot use debugging tools that come with modern browsers to debug Jest tests. Anyway, it is still a framework that just recently came out.
#JEST WEBSTORM DEBUG HOW TO#
When I searched online trying to figure out how to debug a Jest test, I had a hard time finding useful information. However, it throws cryptic call stacks quite often when it runs into issue. Facebook’s Jest framework is very powerful with its automatic mocking which I personally like it a lot.
0 kommentar(er)
