Every debugging session is then fresh as if a user was visiting my application for the first time. I like to configure Visual Studio to launch browser debug sessions in incognito/private browsing mode.

By default, debugging in a browser from Visual Studio opens a new browser window but does not purge any preexisting cache or cookies. Basically Catch-22 debug experience.Īfter enough frustration, I decided to investigate how to debug directly within VSCode since it has been very nice experience when debugging other node applications and in my particular case i was only interested in debugging TypeScript libraries and did not need a browser.When I develop web applications in Visual Studio, I often need to resolve issues that are dependent on the state of the cache or cookies. If you press f8 or Continue to it will load files and execute tests before you have opportunity to set break points within them. Devtools does stop executing for you however, because the files that your test are in have not been loaded yet you cannot set breakpoints on them.

Assuming debugging happens rarely perhaps this is acceptable however, when I tried it I was unsuccessful at debugging. However, this only prints out a url to open chrome dev tools such far as I know, you then have to copy paste this URI in to chrome which is a cumbersome step in the process. This worked out well and I wanted something similar for Jest.Īfter looking at their documentation, github issues, and stackoverflow answers it is possible using a command such as: node -debug-brk -inspect. With Jasmine and Karma, there were chrome launcher plugins that would would open chrome with an generated test runner page which invoked the tests and there I could use Chrome development tools to do my debugging. Being able to put breakpoints in my tests and then step through the source with the inputs from the tests was a valuable part of my workflow on my previous setup using jasmine and karma. I would need to understand why the actual result differed and how it was computed incorrectly.

Often times when the library or set of components under test become more and more complex it is not enough to simply see pass or fail with the actual result and expected result. I recently started using Jest to write and run my tests and I liked almost everything about it except it seems to be missing clarity on how to setup the debug workflow. Note: I have published an updated article on this topic here

Visual studio code debug jest