I am using codePro tool to generate junit. Since I am using JDK1.4, I opted junit3 in codePro settings.
Despite me setting junit-3, the test cases are generated in junit-4 (with annotations)
The first screen shot shows that my setting shows my selection on junit-3
The second screen shot shows that test case generations are happening based on junit-4
Please guide me on this
I found it why it is happening.
Even though I opted junit-3, I was not having junit-3 jar file in my classpath and hence eclipse used junit 4 jar file from its plug-in folder
Now after including junit-3 jar file, am able to generate testcases with junit-3.
Related
I am attempting to generate code coverage for a jar that is in my library. I have a suite of tests that uses this jar and I would like to see how much coverage I am getting with my test suite. In Intellij's run/configuration menu, even if I manually specify to include all the classes in the jar, ex. "com.my.jar.*", I get 0% code coverage. In Eclipse, I was able to easily select the jar, hit 'Coverage', and get accurate results. Has anyone else converting to Intellij from Eclipse experienced the same issue?
I got stuck on this too - I was able to get it working in Eclipse instead of Idea
Now that I am using gradle for all of my new development, I'm running into issues with BuildShip features I really don't want.
For instance, when I hit the Run hotkey when I have a unit test open in Eclipse, I only want it to run as a JUnit test, alone. But Gradle has inserted its own hooks and option, which means extra clicking or keypresses beyond the one-stroke hotkey I have assigned to Run that I can tell it I want JUnit. (The gradle test option actually runs all tests, which takes minutes.).
Question: Is there a way to remove this hook in gradle without diving into the source code and ripping out functionality myself?
This isn't the only interference (interfering with run last is another), but it's my #1 annoyance about BuildShip.
Essentially, I want this popup to stop happening.
Indeed you cannot change the available launchers prompt but you can change the default hotkeys related to each launcher and directly use the one you prefer.
From Windows > Preferences > General > Editor > Keys you can get the list of available hot-key mappings. Filter the (long) list by typing test as show below:
As you can see you have several mappings for running JUnit tests: Gradle, JUnit runner, Maven.
The default configuration for JUnit runner is Alt+Shift+X,T, not really user friendly I would say.
I changed it to a more concise Alt+U down in the Binding option and applied the changes. Now you can run any JUnit test on its open editor windows without any prompt, simply type Alt+U and the JUnit runner will be triggered automatically for that single unit test.
This is a major usability annoyance in Eclipse+Buildship. I perform the following steps every time Buildship upgrades to get rid of that annoying popup, and also avoid the (for me, useless) Gradle test process when what I really want is for the last test to run while I am not in that particular class. Admittedly, this is invasive, but it works while keeping the "good" parts of Buildship.
Open up the plugins folder and look for the org.eclipse.buildship.ui_*.jar. (I do this on a Mac, which requires showing the contents of the Eclipse.app first.) Open the .jar file in some zip file editor which can modify files within the zip file (I use BetterZip on Mac, I think Winzip and 7Zip probably work too.) Edit the plugin.xml file.
This is for the new Photon 4.8 release of Eclipse. Remove (or comment out) the following two sections:
The <command> element with id="org.eclipse.buildship.ui.shortcut.test.run"
The <extension> element with the comment <!-- "Gradle Test" entry in the "Run as... " context menu --> above it (about 30 lines)
Save the file, which should be noticed by BetterZip/Winzip and let it update the .jar file with the changed content. Finally, eclipse needs to be restarted with the -clean switch so that it does not use a cached copy of the jar file. For example, on Mac:
cd /Applications/eclipse-jee-photon-R-macosx-cocoa-x86_64/Eclipse.app/Contents/MacOS
/.eclipse -clean
Buildship will now no longer bother you with that popup or run the Gradle test within Eclipse, because the UI entry points have been removed. Unfortunately, on the next update of Buildship you need to repeat the process again on the new jar.
We have a Java (7) project that uses Maven (3.2.1). We have a Jenkins (1.554) server, and we use it to run code analysis with SonarQube (4.3).
I have configured the default dashboard to show a few treemaps to visualize the test coverage in different parts of the project (using the link Configure widgets -> Category: Filters -> the "Measure Filter as Treemap" widget). The code gets analyzed totally fine, the test coverage gets recorded, the diagrams are colorful and everything is good.
Almost. We are using standard Maven folders for the code, and the package names are in the format "com.ourdomain.someapplication.subdivision.whatever". However, in the treemap diagrams on the dashboard all the packages are displayed as "src/main/java/com/ourdomain/someapplication/subdivision/whatever". As you can see in the attached screenshot, it makes the package names harder to read and the project becomes harder to navigate.
I am sure this is due to a faulty configuration on our part, but is it something to do with Sonar or Maven or Jenkins? Or something else?
Since SonarQube 4.2, all language analysers behave the same way and so indeed the path of all source files is relative to the project root directory. I known this might sound like a regression in your case.
I installed EclEmma for its source annotation abilities relating to code coverage, how it highlights code with various colors based on whether or not that code is hit during execution. I intend to use this information for debugging purposes. The default install adds a "launch with coverage" button, which is what I want. This works perfectly for the entry point into the program; that entire source file gets beautiful coverage information smeared all over it. Unfortunately none of the other project files get the same treatment.
When I go over to the new coverage tab I see my source folder structure and all of my source files are listed along with coverage percentages. This is nice, but I would really like it to add the coverage annotations to my other source files so that I can review code coverage line by line in the rest of my project. Presently even clicking on them in the coverage tab with the percentage sitting directly to the right opens the plain unannotated source file (well, unannotated besides Eclipse's normal annotations for Java code). How can I get EclEmma to add source code coverage information to all of my source files, not just the one containing the point of entry to the program?
I suspect that there is a simple fix that I am missing, but the best I can get from the relevant documentation is how to change the color of the annotations.
For reference I am using Eclipse 4.2.1 for Java development. My EclEmma installation is the one from the Eclipse Marketplace.
Thank you for your time,
-- Techrocket9
For unknown reasons the issue seems to have resolved itself. I can only conclude that the EclEmma does not require alteration to display source annotations for other files, and that a bug in my particular Eclipse install triggered the issue and that the bug was fixed in an Eclipse or EclEmma update.
The JUnit integration with eclipse is very nice. However, I would like a feature to be able to generate a quick report from the Unit Tests. It is possible to do so when running a headless build (and my nightly build is configured to do so), but sometimes I want to generate a report from the UI.
Is there anyway to do this? command line options maybe? an extra plugin? maybe the functionality is already there and I can't find it?
EDIT: I have a PDE build, as my project is an RCP application. Thus, running the tests from this build is not really straight-forward. I guess I could try to hack a smaller ANT script to do the test, but then probably I have to fight with the classpath to obtain what I want. I was hoping to find some extension to the already existing JUnit plugin that would provide the information on the tree view, but as an HTML document.
You can use ant and generate HTML report [I think you can use Ant in Eclipse]
I found these link but you can survey more:
Ant JUnitReport Task
JUnit Tutorial
JUint Report
I'm not sure if you want a "physical" report that you can distribution or just more information you can view in your IDE.
Either way I agree with SjB's advice on configuring Eclipse to run the ant script generating the report in your nightly build.
If it's not possible to run the nightly build locally, you can do some very simple build script hacking following the links in SjB's answer.
You also might want to check out the Ant JUnit Task Manual Page