I'd like to debug my test when it is run by CIDER:
(let [test-system (atom (new-test-system))]
(some-setup-code)
(deftest my-test
;uses test-system in here)
As you see, my tests are wrapped in a let, which gets debugged as normal: I can hit c to move through the forms until it gets to the deftest, then the debugger quits, and my-test is highlighted in red, ready to be debugged when run.
When I run the test with , t t it doesn't debug, it passes as normal. I expected it to break and let me debug inside the test.
What am I doing wrong? I'm rather new to CIDER.
I'm facing a similar issue.
Even if I instrument a function that is called from within the deftest I can't debug it when I execute the test with , t t (cider-test-run-focused-test).
It seems that this action clears out the instrumentation.
If I run the test manually via (clojure.test/run-tests) (switching to the namespace before e.g. via cider-repl-set-ns) I can debug both tests and auxiliary functions without problems.
Related
I am using WebDriverIO to implement a test automation framework in TypeScript. My framework includes some complex models for the application under test and I need to debug in VS Code to ensure that the models have been implemented correctly.
Unfortunately, although I have configured wdio.conf.js and .vscode/launch.json in such a manner as to properly start the debugging session and the execution stops at my breakpoint (most of the time?), I can't add a watch on any variables or properties of my model - nothing gets added in the watch window. Similarly, if I use the debug console, nothing happens when I type in a property name.
I've tried using browser.debug() as per the documentation (https://webdriver.io/docs/debugging.html), but all that seems to be designed for is stopping your code execution so that you can evaluate the state of the application under test in the browser's DevTool console.
Doing console.log(this) in VS COde's debug console when the execution hits browser.debug() returns what looks like a WebDriverIO instance rather than the context of execution.
Has anyone had luck with this sort of thing?
In your code, include the word 'debugger' where you would like the debug execution to break. See example of 'debugger' placement.
describe('Navigate and debug ', () => {
it('should have the correct title', () => {
browser.url('localhost')
debugger
assert.strictEqual(browser.getTitle(), 'foo')
})
})
Its very basic, and its boggling my mind now.
The specific exception message that i see is :
java.lang.ClassCastException
com.company.client.vehicle.model.PerceivedGarageMessageDTO cannot be cast to com.company.client.vehicle.model.PerceivedGarageMessageDTO
The code looks like this
PerceivedGarageMessageDTO p = (PerceivedGarageMessageDTO)obj;
I am using Intellij.
When i view obj in intellij watcher, i see the relevant properties inside obj.
When i evaluate PerceivedGarageMessageDTO p = (PerceivedGarageMessageDTO)obj in evaluate mode, the execution goes fine and the object is typecasted.
When i execute the command in normal debug run by pressing F8, an exception is thrown.
I am unable to figure out the cause of this very very strange issue.
Usually this happens when the class is loaded with different classloaders.
Will fix debugger evaluator within IDEA-203275.
I just started testing with Karma. When i specify a browser in the config-file it basically just opens a window that tells me that the test is idle or running, nothing more and nothing less. That doesn't make sense to me, why would i need a browser for that? Okay i get it you need to debug but thats another page where you can debug isn't it?
Although this site is reloading when Karma is doing something, the other , way more usefull, karma-html-reporter output stays like it is until i reload it manually.
Is there any way to either
(A) Show the test ouput in a html-reporter like fashion on the connected-page?
or
(B) Connect the html-reporter-page to the socket and live-reload it?
I know i can just use the console, but isn't it nice to have some order and styling in all the chaos?
I've got the following code in a thread in my application:
while (true) {
if (ready) {
progressIndicatorController.value++;
return;
}
}
The ready variable is changed from a delegate method. This code works great when I open the application by clicking the "Run" button in Xcode's toolbar. However, if I open this application's .app (which I create by clicking Product > Archive and then following the steps) this code somehow doesn't work anymore.
progressIndicatorController.value is never incremented and this if-statement never evaluates to true. What could cause this problem?
This is probably caused by optimization from the compiler.
When you build with Archive, XCode enabled optimization in the compiler that could throw this kind of code away. I think setting the ready variable to volatile could fix your problem, altough if I were you I'd just try to rewrite it so it doesn't trigger this problem.
You can test with optimization turned on by choosing Edit Schemes in the scheme dropdown. Then set Build Configuration to Release in the Run MyApp.app. Don't forget to set it back to Debug when you're done though, as the debugger gets somewhat confused when optimization are on (i.e. you can't see the value of most variables, some breakpoints may behave erratically, etc...)
I am writing tests for my iPhone app using OCUnit.
Is there any way to debug the unit tests and have a break point to see what the heck is happening?
It's ridiculously hard to write unit tests without being able to use breakpoints.
The link posted by David Gelhar is correct for Xcode 3.
For Xcode 4, things are much simpler. Edit your current scheme and go to the "Test" action. Click the '+' at the bottom and add the test bundle that contains the tests you want to run. Now when you choose Product -> Test, it will run those tests. Any active breakpoints will be hit just like you'd expect.
Using XCode 4.2, (with SenTestKit unit tests as set up by checking the "Include Unit Tests" checkbox when setting up the project), Product->Test wasn't hitting my breakpoints, but Product->Perform Action->Test Without Building seems to do the trick. Hope this helps.
You may have also accidentally disabled "Debugger: Debug Executable" option in Scheme -> Test -> Info
Here's a blog post: Debugging Cocoa application unit tests with instructions for how to do this (for XCode 3 at least; not sure about XCode 4).
Another item to watch for in XCode 4 is that you haven't added the classes being tested to the Unit Test Target as well as the main project. It appears that it's not necessary and it will mess up your ability to have breakpoints hit.
A clue will be warning messages in the debug log when you run. The messages will look like this:
"Class XXX is implemented in both YYY and ZZZ. One of the two will be used. Which one is undefined."
Once I removed the classes noted in the warnings from the unit test target, Xcode started hitting the breakpoints.
You can remove classes from a target by clicking on the .M file, and turning off its membership in the unit test target in the inspector window under "Target Membership".