ScalaTest unit test dont hit breakpoints - scala

So I have a small problem on which google mainly hits wrong results.
It is very simple: I make unit-tests for scala using ScalaTest FunSuite and my breakpoints inside the tests dont hit (Intellij 2016.2.5, previous version was the same,already updates). However when I place breakpoints in code outside of my unit tests the debugger does break. Settings on the breakpoints are exactly similar (ctrl-shift-f8).
So for some mysterious reason breakpoints inside my test will never hit but outside it does (proofs the forking trick is not doing any good). The project is very new still. Running this on another machine does work somehow so I suspect it is some setting in Intellij.
I am a bit lost on this and dont feel like writing mains to hit breakpoints.
Thanks

Related

Scala metals: "Evaluation failed because the thread is not suspended."

So, like the title says, this error comes up as I run the program. However, should I compile the code in any other IDE (tested IntelliJ and it works) or through terminal, it works. How can this be solved?
I have seen other threads, and they seem to suggest that I abandon vs code, but I'd really not want to as it is lightweight and rather fast (does another IDE like this exist?). So, I'd really love a solution to this issue...

Unrea Engine 4.27.1 project always build everything

I use ue4.27.1, by compiling engine source codes.
However, whenever I try to build sources after changing build configuration 'Develpment editor' to 'DebugGame editor' (or the opposite way) it compiles all 4240 modules.
It compiles more than 2700 modules when I press F5 to play it. It often happens but now this always happens.
"Invalidating makefile" or "create makefile(no makefile)" messages are always shown in the log.
I think this got worse when I created a new class for my project, but I'm not that sure about that.
If anyone got any ideas about this, please, please share your knowledge.
btw it didn't happened with 4.26.2 but happens with 4.27

hot swapped warning without making any changes (Spring tool suite 3.9)

When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.

Debugging Protractor with WebStorm

So new to Protractor, so please bear with me.
So I have some simple tests written, and I can run (and sorta debug them in WebStorm). I say sorta debug, because when I run my test, it hits all breakpoints and console.logs before actually executing any of the code. it almost like it goes through the code twice.
As an example, the first thing my test does is go to a page (after loading the landing page).
browser.get('/#/divisions');
If I set a break point after it, it will hit that break point before going to the divisions page. I thought it maybe an async/await issue, but after trying to make everything async, it did the same.
Any idea on what I might be missing?

Can I stop XCode from breaking on a fatalError/preconditionFailure?

I've got some conditions where I need my frameworks to report a fatalError or a preconditionFailure and crash. I have set up some unit tests around these conditions to make sure they hit correctly.
It works really well if the unit tests are run without a Test Host application, but the moment a Test Host application is involved, any fatalError or preconditionFailure hits an automatic XCode break with the message Thread 1: Fatal error: <CUSTOM ERROR HERE>. and stops the execution of the rest of the tests until I press the Continue program execution button manually.
This is obviously an issue because I can't just let my tests run in the background and I need to be actively hitting the Continue button every time one of these tests hits which is quite annoying.
Is there any way to disable this XCode break?
Looks like this is fixed in Nimble 7.1.3, a library which I use to test these particular cases. I also found this specific issue in the Nimble library issue 478 which has a comment on a workaround you can use to disable the debug executable when running you tests. Hopefully this helps anyone else stuck with the same problem I had.