I would like to have something like binding.pry in ruby, basically, I want to be able to add a line to my code, and have a debugger stop there, while karma is running my angular/jasmine tests
it('runs my jasmine test', function () {
var a = true;
binding.pry // stops code and enters REPL prompt
expect(a).toBe(true);
});
The result would then be a prompt
#
Where I could do things to the variables available in that scope, at that point in time
# a = false;
Then I could exit and continue execution.
# exit
Just like debugging with dev tools, but I would like to have this outside of the browser environment and inside the terminal under a karma process.
I've also found https://github.com/alidavut/locus, however it doesn't seem to work under karma.
I'm not aware of any way to launch a repl in the karma process, but what you can do is simply write:
debugger;
at the point where you want to debug. Then, if you have the browser's dev tools already open when that line is executed, the execution will pause and you'll be able to use "watch expressions" which might be enough for you. You have access to the call stack and all the local variables. You can also assign to local variables in a watch expression and the new values will persist when you resume execution.
I've only tested this on Chrome. What I have to do is:
Put the debugger; statement in.
Start karma.
Open the Chrome dev tools.
Save one of the watched karma files (so now the tests will run again with the dev tools already open).
Profit!
Making a REPL on the karma side would require a lot more effort as all the test code is executed on the browser. To control a REPL from the karma process you would need to setup events to communicate via the sockets that karma sets up to talk to the browser. Should be doable though if you're so inclined. EDIT: actually, to do this you would still need to be able to make Javascript block execution at a particular statement, and I'm pretty sure that debugger; is the only way to do this.
Related
This is the first time I've used multithreading in Powershell and Runspaces. My first foray into this is via a form-builder and pre-built runspace code from PoshGUI.com.
I have a form, where a button calls a Microsoft.Graph cmdlet requiring the Microsoft.Graph.Identity.SignIns module. This cmdlet is wrapped up in an Async { } code block (per PoshGUI's implementation of Runspaces), and all seems to work fine.
However I added code to handle module checks and install/import the necessary modules when the script runs. Adding this code to my script seems to break it. First run works fine, but subsequent runs fail with the Async code hanging and never returning. I have to open new PS consoles to re-run the script successfully again. But after each run I have to repeat closing/reopening a new session.
I've since found if remove the import code from the script, it works again as expected, however once I close the script, if I simply manually import that module in the existing PS console I ran the script in initially, the script breaks again until I forcibly unload the module.
In short: forcibly loading a needed module within my script (or the session launching the script) breaks the code running within a runspace that requires that module.
I found a post that suggests there can be issues with reusing runspaces, specifically with certain functions, including importing modules, but no further detail.
Anyone have a clue what is going on here? Even though the app closes, where I assume all the runspaces are destroyed something sticks around it seems.
UPDATE For now I've fixed the issue by not importing the module at all. My module check just installs them if not already installed. When the cmdlets requiring the modules are run, it appears they automatically load the modules those commands belong to (not sure how that works), but the script now runs fine, including subsequent runs.
Still don't understand why it's an issue. Further I thought importing of non-default modules was required. Win PowerShell 5.1 fyi.
I am new to Protractor but aware about the selenium.
Suppose there are 5 TCs in a single spec file and I want to run them sequentially.
Means one TC should be execute at one time but Protractor is running all those TCs simultaneously.
Also, I want to close the browser window after each TCs is being completed (No matter what is the result Pass / Fail).
Can you please help me out on it.
First of all there is no function in protractor called,
browser.open("");
Rather it should be,
browser.get("");
Now your browser will open and launch the AUT. Then you can sequence control flow () , by mentioning beforeEach block for opening and closing the browser.
I'm trying to debug quite a complicated module in my angular app. I've set a break point at the start of a particular method hoping I could follow it through and see where it's giving me back an error. However, it keeps bringing me into the VM scripts (VM28337, VM30559, etc). I can assume these all work as they should, so I have no interest in seeing them.
I know I can blackbox certain scripts in chrome debugger, but there seems to be an endless amount of these VM scripts. Does anyone have any suggestions on how to circumvent these scripts?
This doesn't appear to be possible in any version of Chrome at the moment. However, I create a Chromium bug to request it get added: Chromium Issue 526239
A development-time-only workaround can be to override eval in your page -
(function ()
{
var originalEval = eval;
eval =
function (script)
{
return originalEval(script + "\n//# sourceURL=blackbox-this.js");
}
}());
And then blackbox ^.*blackbox-this.js$
Same for setInterval/setTimeout when it gets a string (but that is a bad practice anyway, right? ;))
Does that work for you?
I would like to run Karma tests inside a web-worker. My reason is that some code could work fine in standard browser environment, but then fail when running in a web worker. Consider the line:
var result = window.Math.abs(-1);
This would work fine in usual browser code, because of the global window object, but it would fail if it was part of a web-worker, because it doesn't have a global window object (unless window has been manually defined somewhere).
I realise I could just write self.Math.abs(-1), or even just Math.abs(-1), but my aim is to get the test to catch such things.
How can Karma run the tests inside of a web-worker?
I have an AngularJS application with about 2000 unit tests which consume a lot of memory. Once tests launched, they run pretty fast (in Chrome) until memory consumption hits 1.5GB at which point every test starts to take about 3 seconds.
Now, I'm pretty damn sure this is not related to Why are my AngularJS, Karma / Jasmine tests running so slowly?.
At this point I have no idea if it's the tests that are leaking or the application itself. I would like to profile the test execution.
I've read unit-tests karma-runner/jasmine profiling and am trying to do the following:
You can use localhost:9876/debug.html and profile the memory. Check the memory before executing (after Jasmine executed all the describe() blocks and collected the tests) and then after executing the tests - it should be the same.
But how can this be done?
I don't really understand how it is possible to check before and after. Can I somehow pause the tests execution? Is jasmine able to tell me when it's "collected the tests" and wait for me to do the profiling?
Or is there any other approach?
This is not a full answer but just "thinking out loud"...
I would start isolating a suite first.
Then I'd start to have a look at the Chrome Console API - so focus on one browser only for the moment .
Now in each beforeEach or afterEach trigger and shutdown the profiler (using a a suite + test name for each profiling): see the console.profile(\[label\]) and console.profileEnd() calls.
At this point you don't need to stop anything to run the profiling, at the end of the testing you'll have all the results (with labels).
Once found the place where the memory goes up you can focus the area and probably start debugging in a more specific way...
We are seeing similar issues in recent Chrome, though we are using Mocha. Interestingly, you can set a debugger and the memory still climbs... This makes me consider that its not our code or even JS heap size, seems like a browser bug?