I am facing a strange issue, while debugging the Unit Test, i put a break point at unit test API (Test_Computation) and another break point at the concrete class ComputationImpl::Computation() which invoked from Test API. While debugging, getting the below issue:
Unable to install breakpoint in com.lok.ComputationImpl$$FastClassByGuice$$983a053 due to missing ine number attributes. Modify compiler options to generate line number attributes. Reason: Absent Line number information
But the TestClass break point is hitting, not the actual class.
I am using amazon correto 1.8, eclipse 2020 (latest).
I followed all options here, but did not help me.
Eclipse - Unable to install breakpoint due to missing line number attributes
Can someone please help on this.
The issue was due to a wrong Mock on class. Its resolved now
Related
I am having the above issue once am running the code. I have changed my language level into 8 and added maven properties into the POM file. But still having this issue. Please help me to resolve this.
Yes as like above comment it's quite difficult to solve problem without any error log or code so if possible please add it.
Else where as per my experience i thought that it's occurred in case where your JDK dependency not bind properly with your project.
In such case you're not able to use that library inside your project. For that go inside "Project settings" inside your IDE and check dependency bind properly(like following image) or not if not then do it first.
I was running into a curious problem today and would like to get some more info on that, as my google-fu proved to be insufficient for that.
What happened
The scenario is as follows: I have a straightforward Netbeans project, which contains a .java file that makes use of some annotations, which are handled by the Netbeans annotation processor (org.openide.filesystems.annotations.LayerGeneratingProcessor to be precise) to create a .xml file during compilation.
All of this worked fine up until today, when I accidentally forgot to add the dependency for the annotation processor to my new project (i.e. core/org-openide-filesystems.jar). Without that dependency being present I witnessed the strangest behavior: a build (via Netbeans as well as directly via ant on the commandline) would report to be successful, yet no .class files were generated at all.
What really threw me off was that the build call come back with a success. Not a single warning or other indicator that something was amiss.. just no classes generated and a tiny little .jar file that only contained the Bundle.properties files, but again no .class files.
The workaround
So much for the scenario itself. After a while I eventually came to find out about a javac option that would lead the compiler to finally tell me that something went wrong: -XDdev. I have never seen this option before and from my googling all I could find was that these kind of options are referred to as Hidden Options. But I haven't found a good listing of what hidden options are available and what they're good for. Any reference on that would be much appreciated.
Anyways, adding this option to the compile, the actual javac call would spit out a large stacktrace that eventually boils down to a ClassNotFoundException for the LayerGeneratorProcessor class. Lo and behold, once I added the dependency for that class to the project everything builds fine again.
The remaining problem
What is funny (as in scary) is that even despite this exception being printed to stderr and indicating that annotation processing failed, the overall javac call succeeds! It still comes back with build successful and acts as if everything was fine. Without the -XDdev option, one would not even have any indication at all from the output that something went wrong.
Finally, my actual question: is there some way to turn this behavior into a proper error? While -XDdev is fine to find out the problem, it requires you to look at the build output, which especially in a CI context will not be feasible. I would like to protect others and myself from accidentally forgetting the dependency in the future by somehow switching this behavior to a proper build error such that we are also notified by the CI system in those cases.
Just been playing around for the first time with IntelliJ IDEA Community edition, first time I have worked with it so if I'm missing something, please excuse me.
I have a bunch of unit tests which I run, however, when running them in IntelliJ (with the standard setup out of the box), I intermittently get the following error in the console:
03:14:17 Failed to start: 58 passed, 1 not started
I have searched the web but to no avail. If I run just the test that failed, it may or may not print out a similar error:
03:19:54 Failed to start: 0 passed, 1 not started
If I keep trying, eventually it works and tells me that all of my tests have passed.
The image is not the error as an exclamation mark, it is a different error icon (), which I do not recognise. The error in Event Log window appears as red text.
It always appears to happen with only one test and it is always the same test for any given set of tests. I.E. In a different project, the same issue also appears, but for a different test (but it's always the same one in each project or set of tests).
One more thing to note is that this ONLY happens when debugging and not when running, so it may be something to do with connecting the debugger?
It all works perfectly fine with Eclipse.
Any ideas what could be causing this?
The issue for me is Failed to start: 1, passed: 0 . I'm using Spring Boot 2.4.0 with Junit5 to test the Controller Class. I just commented out the version tag in the junit-jupiter-engine dependency. Then it worked. Really strange. It might helpful for someone.
I got the same error. It was something weird sent to System.out that made IntellJ IDEA test "not started".
I've created a ticket for IntelliJ IDEA, you can vote for it if you still encounter this problem.
In my case problem was in pom.
I moved from fulling working application to spring-boot implementation and only imported spring-boot-starter-test in dependency for testing.
I solved by excluding junit part from spring-boot-starter-test and added junit dependency of latest version in separate block.
Sometimes similar error happens with scala code when you mix sclamock's MockFactory with scalatest's AsyncFlatSpec.
So, be sure to use AsyncMockFactory like below.
class ExampleSpec extends AsyncFlatSpec with AsyncMockFactory
Looks like this may have been a bug on IntelliJ, it has been raised with them.
I had this problem (in Android Studio but its a customised IntelliJ) and the reason was WHERE the cursor was when I ran tests using CTRL-SHIFT-F10.
#Parameterized.Parameters
public static Collection data()
Once I moved the cursor into a test method or not inside any method, it worked.
I had the same issue. Whatever be the number of scenarios, it was showing 1 extra scenario in NOT STARTED stage. I was using Scenario Outline to run tests and had commented the rows in the Example tables.
I later found out that commenting the whole example table (which I didn't wanted to run) resolved the issue rather than commenting each row.
I had the same issue that cracked me up a little in IntelliJ IDEA 2017.2.1. The test case ran without any recognizable errors or irregularities, but in the end JUnit claimed the case as not started.
Figured out it was caused by trying to print into a PrintWriter that has already been closed.
In my case I was trying to mock a class having a public static method. Problem solved when everything is set free from static context.
I came along not started tests, when attempting to test code that called System.exit(1) . IntelliJ would not start my tests until I removed the exiting behavior like this:
At first I replaced all direct lines in the code from
System.exit(1)
to
onFailure.run();
with
unnable onFailure = () -> System.exit(1);
in the code itself. In the Test-Code I replaced the Runnable with a testable mock Runnable
Runnable mockOnFailure =
() -> {
throw new CustomError(
"Some descriptive message here.");
};
and than I expected that Error to be thrown like so (using AssertJ for nice assertion statements)
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatExceptionOfType;
assertThatExceptionOfType(CustomError.class).isThrownBy(
() -> {
callingCodeThatCallsOnFailure();
}
);
Now the tests are all being startet by the IDE as desired.
Feel free to reuse that if it is of help to you. I do not claim any ownership or copyright to any of those lines of code.
I get on my local machine the following exception when running the tests by maven (mvn test).
ch.qos.logback.core.joran.event.SaxEventRecorder#195ed659 - Parser configuration error occured
java.lang.ClassCastException: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
After googling around I came across several pages which describe the main problem behind it (several SAXParserFactoryImpl in different classloaders).
-> http://www.xinotes.org/notes/note/702/
My question is, how can I figure out which library is also providing the SAXParserFactoryImpl, so that I can exclude it. I am using Maven, IntelliJ and JDK 1.6.0_23. The issue occurs on the command line as well as when running the tests from IntelliJ.
But the strange issue is, that on the build server this issue doesn't occur.
Update 1
Just figured out when I run the first time mvn test after an mvn clean, the error doesn't appear. But as soon as I run mvn test again (without clean, the exception occurs) (when I run it from IntelliJ).
When I run it on the cmd line, then several mvn test calls do work.
I found the issue. It was related to PowerMockito who tried to load the SAXParserFactory. The reason why I haven't figured that one out was because the stacktrace contained only twice PowerMockito, and this at the middle :-)
So If you figure out this problem in IntelliJ and you do use PowerMockito, annotate your test class with the following annotation:
#PowerMockIgnore(["javax.management.*", "javax.xml.parsers.*",
"com.sun.org.apache.xerces.internal.jaxp.*", "ch.qos.logback.*", "org.slf4j.*"])
This has solved the problem in my case.
Your JDK probably has its own SAXParserFactoryImpl.
Check for jars like xercesImpl, xml/xml-api and sax.
One your server the one from the server is probably going to be used.
You can use a jarfinder: http://www.jarfinder.com/index.php/java/search/~SAXParserFactoryImpl~
I encountered the same error today. After a lot of digging, I found that the solutions here, or on other places are not helpful.
However, after playing around, I found a solution that works deterministically, unlike the accepted answer which does not apply to all cases.
The answer is, look through stack trace to find any ClassCast exceptions, and just add them to \#PowerMockIgnore list. Keep repeating until the issue is solved. Worked like magic for me.
Hi i am new to cactus and when i am using tomcat5.1 and have included all the necessary jars. But when i am trying to execute it, it is showing the error,
Error : "javax.servlet.ServletException: Failed to load test suite [SampleTest], Reason is [Class not found "SampleTest"] "
Please let me know what the problem is??
If you are trying to run the Quick Start tutorial from the Cactus web site, I believe it no longer works.
Here's a mention in the release notes of 1.8.1.
Release Notes - Cactus - Version 1.8.1
Bug
* [CACTUS-124] - Cannot run the Servlet Example
I get the same error message with version 1.7.x.
I just started researching this product, so I'll post an answer if I find one. Hopefully someone else will have an answer with the extra info I have provided.
EDIT:
Found a work around. Looks like it's an issue with package names. I re-compiled the two files using the default/no package and it worked.
EDIT 2:
I looked up CACTUS-124 in the bug database and it's not related. Also I believe only the class files that extend ServletTestCase need to be changed to the default/no package name.
You need to include the package ie:
http://localhost:8080/myapp/ServletTestRunner?suite=common.TestEverything
Would run the suite TestEverything in the common package.