Unit testing some projects can take some time, and with multiple projects you have to start them one at-a-time sequentially. In NetBeans is it possible to run all unit tests for a single project in one go.
Is it also possible execute all unit tests for all projects in one go?
In NetBeans is it possible to run all unit tests for a single project in one go.
In NetBeans 7.1, yes, it is. See my previous answer to this same question.
Is it also possible execute all unit tests for all projects in one go?
I don't believe that this is possible.
In NetBeans is it possible to run all unit tests for a single project in one go.
This is possible by right clicking the project node in the Projects explorer and choosing Test from the context menu. You can also use the key board shortcut Alt+F6 to achieve the same result.
Yes in Netbeans also it is possible go to current project Properties by right clicking it, and go to Libraries, there u can add your other projects to run in a single go.
Related
Am I able to use Jubula to test the entire Eclipse IDE?
What I want to achieve is that let Jubula to automatically detect the actions performed in the Eclipse IDE such as "right click a project and rename the selected project". Therefore, I am able to reuse these recorded actions for my test purpose.
If it is possible, which Toolkit (rcp, swing, swt etc.) should I use for this?
Of course, it's possible.
You need to use the RCP toolkit and set eclipse.exe (or whichever your system binary is) as the AUT.
You don't want workspaces to collide: You can use the Jubula standalone or you need to run two instances of Eclipse. When you execute a Test Job, it will start the (or seek for a running) instance of the Eclipse. Thus you need two workspace folders; one for Jubula/Eclipse executing the tests, another for the Eclipse being tested.
You can use the Observation mode to detect the actions you perform. It's disadvantage is that this way your tests will be less reusable and harder to modify. If there's a change in the actions, then you better record the whole process again.
Or you can create your tests manually by adding Test Cases and controller mappings. This requires more practice/time.
If you don't want to spend much time with it then just use the Observation mode.
We use gradle as our build tool and use the idea plugin to be able to generate the project/module files. The process for a new developer on the project would look like this:
pull from source control.
run 'gradle idea'.
open idea and be able to develop without any further setup.
This all works nicely, but generally only gets exercised when a new developer joins or someone gets a new machine. I would really like to automate the testing of this more frequently in the same way we automate our unit/integration tests as part of our continuous integration process.
Does anyone know if this is possible and if there is any libraries for doing this kind of thing?
You can also substitue idea for eclipse as we have a similar process for those that prefer using eclipse.
The second step (with or without step one) is easy to smoke test (just execute the task as part of a CI build), the third one less so. However, if you are following best practices and regenerate IDEA files rather than committing them to source control, developers will likely perform both steps more or less regularly (e.g. every time a dependency changes).
As Peter noted, the real challenge is step #3. The first 2 ones are solved by your SCM plugin and gradle task. You could try automating the last task by doing something like this
identify the proper command line option, on your platform, that opens a specified intellij project from the command line
find a simple good enough scenario that could validate that the generated project is working as it should. E.g. make a clean then build. Make sure you can reproduce these steps using keyboard shortcuts only. Validation could be made by validating either produced artifacts or test result reports, etc
use an external library, like Robot, to program the starting of intellij and the running of your keyboards. Here's a simple example with Robot. Use a dynamic language with inbuilt console instead of pure Java for that, it will speed your scripting a lot...
Another idea would be to include a daemon plugin in intellij to pass back the commands from external CLI. Otherwise take contact with the intellij team, they may have something to ease your work here.
Notes:
beware of false negatives: any failure could be caused by external issues, like project instability. Try to make sure you only build from a validated working project...
beware of false positives: any assumption / unchecked result code could hide issues. Make sure you clean properly the workspace, installation, to have a repeatable state and standard scenario matching first use.
Final thoughts: while interesting from a theoretical angle, this automation exercise may not bring all the required results, i.e. the validation of the platform. Still it's an interesting learning experience and could serve as a material for a nice short talk, especially if you find out interesting stuff. Make it a beer challenger with your team when you have a few idle hours to try to see who can implement the fastest a working solution ;) Good luck!
I am working with eclipse on a mavenized project which has a significant number of modules/subfolders/maven subprojects.
Whenever I look for a resource, or make any kind of research, it shows me every occurrences in every project times two because of the target folder...
example:
projectA/projectB/src/main/resource/.../Foo.xml
if I look for a string that is in foo.xml, it will show:
projectA/projectB/src/main/resource/.../Foo.xml
projectB/src/main/resource/.../Foo.xml
projectA/projectB/target/main/resource/.../Foo.xml
projectA/projectB/target/main/resource/.../Foo.xml
That is a lot for one file. Besides, let say that the prohectA is intended to create a pom, not a war, a jar, or a ear... The problem is now, that if I select this entry, I won't be able to use the auto completion, or the inspect element functionality (that I can't work without!!!!). Even worse: if i select a target directory, my changes will be overwritten on the next maven build...
What can I do? At the moment, I am just paying attention, but it is kind of painful... And I do not have time to go through all the project to mark them one by one as derived (basically around 1000 clicks), so they do not come up in the searches... Besides, the target folder would just appear again after the next maven build.
Any ideas?
The perfect way would be to have eclipse recognize the subproject nature of these, and not show the different occurrences... and maybe setup a filter for the target resources... I do not know if it is possible.
I am also willing to write a tiny script, if people are kind enough to explain to me what eclipse files it should modify in order to accomplish this.
Import the sub projects as separate Eclipse projects (this should happen automatically if you point the Maven import wizard at the master project directory). Keep the master project closed if you're not editing it. You'll still get the target folder version of resources, but at least only once.
You could use that AutoDeriv Eclipse plugin here AutoDeriv to list the paths you'd like to mark as derived, and discard from research etc. as you would do in a .gitignore file.
Once it's done, resources are always correctly marked as derived, even after a maven clean/install.
[edit]
You can write rules at workspace level, to handle several projects at once.
Exclusion rules allows you to mark everything as derived, except for a peculiar folder or file.
Since the 1.3.0 version, Eclipse decoration helps you to quickly see the effects of the plugin.
Disclamer, I wrote it =)
Assume there are Java project and Junit project in an Eclipse workspace. And All the unit tests are located in the Junit project and dependent on the application Java project. When making changes to a Java method, I need to find the unit tests that are using the method directly or indirectly, so that I can run the corresponding tests locally in my PC before checking into source control. I don't want to run the entire junit project since it takes time.
I could use Eclipse call hierarchy to expand caller methods one by one until I find a test method. But for a project including more than 1 million lines of source code, digging down the call hierarchy takes time too.
The search scope within call hierarchy view doesn't seem help much.
Appreciate any help.
Use a test coverage tool. See my answer:
How do I find all the unit tests that may directly or indirectly call a given method? (.net)
Why not right click on the changed method and select "References->Workspace (or Working Set if configured properly)".
This should give you a list of methods invoking the one you just changed. The search results can be organized by package or project. Select project organization and expand the JUnit project and what you are looking for will likely be the only thing there.
I want to add a view to a perspective without having access to the source code of the perspective. Is this possible?
Is there a good tutorial for plug-in development using TDD?
[edit]
I think I have a good starting point with TDDing in plugin development
Automating unit tests (junit) for Eclipse Plugin development
[edit 02/17/09]
I was able to download the source for the plug-in. I'm just probably going to fork it.
Testing GUIs is a PAIN! And the pain grows exponentially with the complexity of the gui design. Your best bet is to keep the business logic separate from the GUI as much as possible with the MVC pattern and when testing the gui, hook the GUI up to a "mock" application.
See Object Mentor's paper, the Humble Dialog Box
You might want to take a look at the org.eclipse.ui.perspectiveExtensions Extension Point.
And here is a nice article concerning Perspectives: Using Perspectives in the Eclipse UI
Sorry, can't help you with the TDD part of your question.
If your goal is to simply add the view to a perspective in your own Eclipse instance, you can just open it when being in that perspective, and choose Window -> Save Perspective As...
For unit testing plug-ins, you can basically test them using normal JUnit tests, which you run as JUnit plug-in tests instead of normal JUnit tests in Eclipse. For GUI testing you could check out SWTBot.