Develop Reference

Suppress error message in JUnit for a forced/known error in eclipse?

So, I'm just making some sample test cases in JUnit using eclipse. One of my examples is to create a simple add(int, int) method and test that a String can't be one of the params. assertFalse(myclass.add("a",5)); My issue is that Eclipse shows that error icon next to the number line and underlines the add method w/ the red error line. It also ask's if I want to proceed when I hit compile. Is there a way suppress this warning since I am forcing it to happen, or is this a bad testing practice? I can always hit ignore for compilation but the red x still remains which is annoying.

You donot need to test for this as it is already a compile error. Nobody can write that code and get it to compile, so why test for it.
As to your question: No, you cannot tell Eclipse to surpress a compiler error.
The fact that Eclipse let's you run this code at all is actually a feature of the Eclipse Compiler. It will insert a special Exception at the spot of the compile error and continue compiling your classes. If during execution of the code a part of the code is hit that couldn't be compiled, this exception is thrown instead.
This allows for fast turnovers when testing code, as you can run a part of your project (like a JUnit test) without having to fix all errors in a project first.

How do I get code coverage from XSpec

I am using XSpec at work for XSL unit tests. I see XSpec as a coverage option but I cannot get it to work. I get this error:
"Transformation failed: Failed to load com.jenitennison.xslt.tests.XSLTCoverageTr
aceListener
Testing with SAXON 9.1.0.7"
I am having a tough time finding recent information about XSpec. Can any one point me in the right direction? Thanks!

Code coverage in XSpec is currently not working. I posted a pull request that should fix the code coverage: https://github.com/expath/xspec/pull/80. If you want to fix it in your version of XSpec before the next release, look at the commit changes in files xspec.sh and XSLTCoverageTraceListener.java (see https://github.com/expath/xspec/pull/80/files).
Note that code coverage now works only with SaxonEE and SaxonPE (not Saxon HE) as the Java class requires extension functions which are only available with these two versions of Saxon.

Logs from one Test class are displayed in other class's Standard output section in Gradle Test reports

I am using TestNG (with gradle) for parallel test execution.
Gradle Task for executing my tests :-
task executeTests(type: Test) {
useTestNG{
options ->
options.parallel = 'classes'
options.threadCount = 2
}
}
I have some logging in tests. In Gradle reports logs of one test class are being printed in standard output section of some other test class when we execute tests in parallel.
To debug, I created 3 classes with one test each and printed Thread.currentThread().getId() with logs. In Gradle reports, last executed Test class's standard output section has logs with different thread ID's(these are from a different class).
Am I doing something wrong? How to get logging correct (I should be able to see the complete logging of a test class in its standard output section). Thanks in Advance.

Gradle's test reporting has been implemented with Gradle's own parallel execution in mind, which is always single-thread-per-JVM (but possibly multi-JVM). Unless you need TestNG's notion of dependencies between tests, you will be better off using Gradle's parallel execution (e.g. executeTests.maxParallelForks = 2), which doesn't have this problem. Also, you could raise an issue for the original problem at http://forums.gradle.org.

Selenium JUnit Tests failed

I am learning Selenium with the aim of exporting UI tests into JUnit tests and then running them in a CI build.
As a basic test I have a Suite.java and a BasicTest.java which is a test case.
I have used the Selenium export and saved the files to the same location.
When I try and compile the tests it fails.
1st Error - http://pastebin.com/0j37KZ08
To get past this error I add an import to the Suite.java for the BasicTest class, which then gives me the following error:
2nd Error - http://pastebin.com/PKxmdj3L
Source code:
Suite.java - http://pastebin.com/Q6HVNtqT
BasicTest.java - http://pastebin.com/fKCk6iN2
Ant build.xml - http://pastebin.com/x16zHKP0
Any help appreciated.

I don't know if you need a Suite here. The issue seems to be that you are calling addTestSuite() with your BasicTest.class which does not extend junit.framework.TestCase. You should see this if you scrutinize the second error message closely. Of course, you would not subclass junit.framework.TestCase for a JUnit4-style test, so there's a disconnect here as far as what the Suite/framework expects and what you are providing. Maybe just avoid using a suite altogether--personally, I haven't bothered much with suites for some time now. Or, if you are following an example that insists on a suite, you can switch over to the JUnit3-style for purposes of learning.
EDIT: This link should help with JUnit4-style suites if you decide you want to keep the suite.

Hudson's FindBugs plugin reports line number "-1" for bugs. Ideas?

Greetings,
I have a simple test project set up in Hudson and the project's build process (a batch file) generates a findbugs.xml file. This is processed by Hudson's FindBugs plugin but it shows the line number of the bugs as "-1" instead of their actual line number. A coworker suggested I enable debug info for the compiler. I used the -g "Generate all debugging info" option for javac but nothing seemed to change. My build command is:
javac -g -classpath C:\testWebApp1\src -d C:\testWebApp1\build C:\testWebApp1\src\*.java
The only other thing in the build.bat file is a call to the FindBug tool (text UI). Here is what the FindBugs Plugin says about the first bug:
File: GenerateHellos.java, Line: -1, Type: UUF_UNUSED_FIELD, Priority: Normal, Category: PERFORMANCE
Any ideas? Thanks a ton!

This is half of an answer:
You have an unused field declared in that class. FindBugs uses static analysis of byte code to find bugs; unfortunately, the byte code format does not store line numbers for class or member fields, so FindBugs can't actually report a line number. There's got to be some switch that will allow it to output more helpful information (i.e. the name of the field), but I have no idea.
Alternatively, you might try PMD, which is a lot noisier, but actually analyzes the source code and also integrates with Hudson.
Did a little more digging and it looks like this is probably a bug in the inspector for that bug pattern. Assuming that your FindBugs run is configured with a n appropriate source directory (i.e., using -sourcepath), the majority of the bugs found should have line numbers associated with them. To check this, open the outputted report. You should see elements like the following:
<!-- skipping a bit -->
<BugInstance type="...">
<Class classname="com.example.MyClass">
<!-- ... -->
</Class>
<!-- ... -->
<SourceLine classname="com.example.MyClass" start="5" end="5" sourcefile="MyClass.java"/>
</BugInstance>
The key there is the <SourceLine classname="..."/>, which reports the line number that the bug was found on. For numerous other inspections, including those for unread fields and a couple of other cases where their are no line numbers in the byte code, this line is filled in correctly, but not for UUF_UNUSED_FIELD. Hence, the Hudson plugin is doing the sensible thing and reporting line = -1.
The Eclipse plugin, however, which has access to Eclipse's rich metadata about the source code is able to locate the field by matching the field name, hence, it appearing to work in Eclipse (if you delete the field in question in Eclipse you should see the bug show up on the first line of the file; other bugs show up on the line number specified in the XML report).
No fix, but hopefully that clarifies what is happening.

You are almost there with the -g. Findbugs is based on bytecode analysis, and depends on the debugging information that is in the class files, your coworker is right about that.
You also need to clean out any previously generated class files, as the compiler is based on timestamps, and won't regenerate files that appear up-to-date.