am I correct in thinking that nodeclipse does not yet provide unit test integration à la JUnit?
I was hoping to be able to run tests individually, by script, by folder... but can't seem to find a way to do that.
Eric
It is open issue #34 in the Noodeclipse project issue tracker, so no.
As Node.js is using JavaScript, so you should actually search for JUnit-like integration for JavaScript.
And there are many unit testing framework for JavaScript,
and I don't know any mature Eclipse integration.
Quick search right now gives me
https://github.com/wgroeneveld/jasmine-junit-runner
JavaScript tests with JUnit
(source: benjiweber.co.uk)
I remember there were some others, but they all required tedious set-up work.
I don't know which project worth including into Nodeclipse.
You can help Nodeclipse by researching and giving more options here
or directly to #34
Related
I am trying to write e2e integration tests for a vscode extension. I didn't find any ui integration tests. Can you please provide me the links if any
I recommend using extensions/vscode-api-tests/src/singlefolder-tests/editor.test.ts in the vscode sources as a starting point for integration tests. If that particular test isn't quite what you want, there are a bunch of tests adjacent to it that might be.
See also this answer I gave to a related question about using the API from within tests.
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 would like to be able to create FogBugz cases directly straight from the editor in NetBeans. Specifically, I would like to be able to look at a JUnit run in the IDE, examine the failures and create cases directly using the information that is right in front of me (rather than cutting and pasting into a web browser, etc).
I see that NetBeans 6.5.1 ships with Bugzilla available by default and JIRA connectivity in some sort of beta form. Is there an equivalent FogBugz issue tracker?
PS: I am aware of the new plugin architecture of FogBugz 7. However, I have a realistic appreciation of the time that I would be able to commit to creating my own plugin for either NetBeans and / or FogBugz and I suspect that I would be able to make just enough of a partial solution to make my life worse rather than better.
It appears you may need to write one yourself, as they have plugins for Eclipse and Visual Studio, but not Netbeans.
http://www.fogcreek.com/fogbugz/blog/post/Eclipse-Plugin-For-FogBugz.aspx
I am not aware of such plugin. You're right that it is not trivial effort to write full-featured connector, but getting basic one is not that hard ... especially if you're already familiar with NetBeans plugin architecture. If you decide to go for it, take a look at FogBugz API instead of new FogBugz plugins. FogBugz API is used to talk to remote FogBugz repositories.
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.
I've used the MIT Continuous testing plugin in the past, but it has long since passed out of date and is no longer compatible with anything approaching a modern release of Eclipse.
Does anyone have a good replacement? Free, naturally, is preferred.
I found that Infinitest now has an Eclipse plugin that seems to work pretty well.
There is a list in this Ben Rady article at Object Mentor: Continuous Testing Explained. Unfortunately the only Eclipse tool appears to be CT-Eclipse which is not currently maintained either.
There is also Fireworks for IntelliJ and Infinitest which is not IDE specific but also has some IntelliJ integration.
My experience is that continuous testing within the IDE can become unwieldy and distracting, so I prefer to use something like CruiseControl to do this kind of testing. One tool I have found very useful is EclEmma, which gives you a very fast coverage turnaround for your units, helping you to decide when you have finished testing a particular area of the code.
Infinitest decides what tests it wants to run. Often it runs the wrong ones. Green bar sometimes good, sometimes meaningless.
I've had good experience with infinitest on a small and simple project. I've not run into any issues with it and find it fast and helpful.
I also use Infinitest (and voted for one of its answers), but I wanted to add another approach, which relies on the build server. Whenever you want to implement something, create a branch in your VCS, do your changes, commit to your branch. If you have a build server configured, which runs unit tests on every checkin, your unit tests are then run on the build server without actually having polluted the trunk (or HEAD, whatever you call it) and without you waiting for the test run to finish.
I admit that this is not really continuous unit testing in the sense you asked the question, but for large projects or large test suites even a "normal" continuous test runner may slow you down way to much.
For small projects I also recommend Infinitest or CT Eclipse.