I know we can use System.printTimeinMillis() method at the start and end of the program. But imagine having this for every executable in the project and checking in that code in CVS.
When Junit test cases are run i see execution time of the test case as 14.662s from the attached. When you run your program over and over making code changes its a great means to see if there is any improvement.
Is there any way(inbuilt option or plugin) i can have eclipse printing out time taken after every execution on console?
I have come across a plugin but its not working on Eclipse Juno 4.1 version.
Related
Pycharm, and evidently the JetBrains IDE in general (due to a similar problem with IntelliJ), has difficulty with mundane operations, like opening a project. Specifically, aside from taking a good deal of time to reindex, it actually takes forever, as in never finishing, and freezing or slowing the entire computer's system in the process of "updating python paths".
On the recommendation of a fellow developer, and also related SO (Stack Overflow) post Why is IntelliJ IDEA hanging on "Indexing"? , I followed the advice given:
"In the File menu, select Invalidate Caches / Restart... and then click the Invalidate and Restart button."
And the caveat left in the comment:
"This worked for me but you have to be quick as if you can't get to the menu fast enough it freezes again."
There is also this from JetBrains
Nothing really special in code, but there are a substantial number of imports that are part of the project, including many pip loaded libs. Also using a virtual environment, but owing to the above discussion, don't believe that has bearing on the difficulty. There are other project dependencies, but again, I don't think any are circular (I know Java IDE wouldn't allow), couldn't vouch for third-party libs. Have not experienced similar occurrence working in Eclipse, but unable to shift project work there presently. Using Pycharm Pro 2018.2.7 on Mac OSX 10.13.4
Just run of the mill import statements:
import python-logstash
One expects a project will open in an IDE without crashing one's computer. Having to open twice or thrice or more each time a project is closed (following the menu File, Invalidate caches/Restart...) is weird in paid software, for a known issue. And there is also always the race to run reopen before computer freezes.
Doesn't happen on a very simple project. What is the trigger? Will JetBrains ever fix? Can one change code or imports to avoid?
In Eclipse there is an option under Run/Debug configuration Keep JUnit running after a test when debugging.
Googling for that phrase only returns one hit, a bug report at Eclipse (61174), that is no manual, instruction or similar. Hence I have two questions:
What does this option affect?
The reason I found this option was that I was looking for a way to make running a test faster. Currently it takes 35 seconds for JUnit to start while running the actual tests usually just takes a few seconds. This is very annoying when I debug test cases and need to start/stop them frequently. Is there a way to make JUnit launch faster?
Yes, I've ran into this myself:
A JUnit launch configuration has a "keep alive" option. If your Java virtual machine supports "hot code replacement" you can fix the code and rerun the test without restarting the full test run. To enable this option select the Keep JUnit running after a test run when debugging checkbox in the JUnit launch configuration.
From the site: http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-junit.htm
I have recently started developing an Eclipse plugin (which is basic stuff for now) and I am struggling with "default" way to run Eclipse plugin ("Run as Eclipse application").
The Eclipse is starting another instance with my plugin already installed in it (this is default behaviour).
The problem is that when I want to re-run my plugin project and I press "run" button again (or Ctrl + F11) (and the another Eclipse instance still running) I get following message:
"Could not launch the application because the associated workspace is currently in use by another Eclipse application".
The error makes sense, and when I close "testing" Eclipse instance I am able to run my plugin again.
The question is - "is it normal routine for plugin development?". Maybe I am missing something, e.g. special arguments for Eclipse?
This seems all pretty normal. The error message is since the run configuration is specifing a workspace and when you start a second instance using the same workspace it is locked and considered in use.
What I usually do when testing a plugin is to create a run configuration (click "Run...") where I disable all the plugins I wont need when testing. This makes sure that the test starts up a couple of seconds quicker. Make sure you save that run configuration as a *.launch file aswell, that makes it quicker to test the next time. Or it can be used to share the configuration.
There's a lot you can configure in the run configuration, such as eclipse arguments, vm argument, if you want environment variables set, etc. So be sure to experiment a little.
In your run configuration. Main tab->Workspace Data ->Location text box add this:
${workspace_loc}/../runtime-EclipseApplication${current_date:yyyyMMdd_HHmmss}
Note the suffix ${current_date:yyyyMMdd_HHmmss} by this every time you launch your application new workspace will be created. So you will not get any error message saying workspace is locked.
But be careful as the folder .metadata will be different for different instances as their work-spaces are different. Thus preferences stored/retrieved by different instances are NOT in sync.
You are probably missing one important point: Eclipse supports the Java hot code replacement. Therefore in many cases you can modify your Java code while your application Eclipse instance is running, save the code and continue without restarting.
If hot code replacement is not possible, Eclipse will tell you, so you always know whether the editing changes are applied to the running instance.
This works best with more recent versions of the JVM, so consider upgrading to the latest Java 7 version, even if you write code to be compliant with Java 1.5 or 6.
I have a LARGE project including python and javascript code that keeps trying to generate stubs for ruby core now and then. The project has no ruby code at all. But every so often Eclipse/Aptana Studio decides to generate stubs, and it takes over an hour. Seriously. I am not even exaggerating.
So of course I have tried many ways to attempt to stop this process. The result is simply that it has to complete before my project is usable again. At the end of the process, the eclipse ".project" file will end up having an entry for "rubyaspect" which we always delete, because as soon as anyone else does a "git pull" on a project with ruby aspect, their environment ALSO spends over an hour generating ruby stubs.
I have seen some discussion on a bug in cancelling the process, but it appears that the question is still coming from people that are actually using ruby. Again, this is a python and javascript project only.
Is there any workaround to stopping this process that won't result in restarting the process as soon as I start eclipse again?
ADDENDUM: The Eclipse version in use is Juno, and the AptanaStudio version is 3.2.0
SECOND ADDENDUM: I have just upgraded to AptanaStudio version is 3.2.1. The same problem persists, but without any mention of ruby core -- it just says "Rebuilding". When it's done, an hour later, it still has added rubyaspect to the project.
--jeff
There are a ton of questions here on SO regarding NUnit vs. MSTest, and I have read quite a few of them. I think my question here is slightly different enough to post separately.
When I started to use C#, I never even considered looking at MSTest because I was so used to not having it available when I was using C++ previously. I basically forgot all about it. :) So I started with NUnit, and loved it. Tests were very easy to set up, and testing wasn't too painful -- just launch the IDE and run the tests!
As many here have pointed out, NUnit has frequent updates, while MSTest is only updated as often as the IDE. That's not necessarily a problem if you don't need to be on the bleeding edge of TDD (which I'm not), but the problem I was having with frequent updates is keeping all of the systems up-to-date. I use about four or five different PCs daily, and while updating all of them isn't a huge deal, I was hoping for a way to make my code compile properly on systems with an older version of NUnit. Since my project referenced the NUnit install folder, when I upgraded the framework, any computers with the older framework installed would no longer be able to compile my project. I tried to combat the problem by created a common folder in SVN that had just the NUnit DLLs, but even then it would somehow complain about the version number of the binary. Is there a way to get around this issue? This is what made me stop using the first time.
Then one day I remembered MSTest, and decided to give it a try. I loved that it was integrated into the IDE. CTRL-R,CTRL-A, all tests run. How simple! But then I saw that the types of tests available in MSTest were pretty limited. I didn't know how many I'd actually really need, but I figured I should go back to NUnit, and I did.
About now I was starting to have to debug unit tests, and the only way I could figure out how to do it in NUnit was to set NUnit as the startup application, then set breakpoints in my tests. Then in the NUnit GUI, I would run the tests to hit the breakpoints. This was a complete PITA. I then looked at the MSTest GUI again, and saw that I could just click Debug there and it would execute my tests! WOW! Now that was the killer feature that swayed me back in favor of MSTest.
Right now, I'm back using MSTest. Unfortunately, today I started to think about daily builds and did some searching on Tinderbox, which is the only tool I had heard of before for this sort of thing. This then opened up my eyes to other tools like buildbot and TFS. So the problem here is that I think MSTest is guaranteed to lock me into TFS for automated daily builds, or continuous integration, or whatever the buzzword is. My company can't afford to get locked into MS-only solutions (other than VS), so I want to examine other choices.
I'm perfectly fine to go back to NUnit. I'm not thrilled about rewriting 100+ unit tests, but that's the way it goes. However, I'd really love for someone to explain how to squash those two issues of mine, which in summary are:
how do I setup NUnit and my project so that I don't have to keep upgrading it on every system to make my project build?
how do I get easier debugging of unit tests? My approach was a pain because I'd have to keep switching between NUnit and the default app to test / run my application. I saw a post here on SO that mentioned NUnitIt on codeplex, but I haven't any experience with it.
UPDATE -- I'm comparing stuff in my development VM, and so far, NUnitit is quite nice. It's easy to install (one click), and I just point it to whatever NUnit binaries are in my SVN externals folder. Not bad! I also went into VS -> Tools -> Options -> Keyboard and changed my mapping for CTRL-R,CTRL-A to map to NUnitit.Connect.DebugGUI. Not perfect since I haven't figured out how to make NUnit automatically run the tests when it's opened, but it's pretty good. And debugging works as it should now!
UPDATE #2 -- I installed TestDriven.Net and gave it a quick run through. Overall, I like it a lot better than NUnitit, but at the moment, NUnitit wins because it's free, and since it also works with NUnit, it will allow me to "upgrade" to TestDriven.Net when the time comes. The thing I like most about TestDriven.Net is that when I double click on the failed test, it takes me right to the line in the test that had failed, while NUnit + NUnitit doesn't seem to be capable of this. Has anyone been able to make this link between the NUnit GUI and the VS IDE happen?
Many projects I've worked on have included a copy of the specific version of NUnit (or xUnit.net, whatever) in a "lib" or "extrernal" or "libraries" folder in their source control, and reference that location for building all of their tests. This greatly reduces the "upgrade everyone" headache, since you really don't need to install NUnit or xUnit.net to use it.
This approach will still let you use something like TestDriven.Net to execute the tests, run the tests in a debugger, etc.
For easier debugging (and running, too) of unit tests I recommend checking out TestDriven.Net. The "Test With > Debugger" feature is so handy. The personal version is free.
Have you played with the "Specific Version" property on the NUnit.framework reference? We keep ours set to true so that the tests that are coded for a given nunit version require that specific version to execute.
I'm not sure how it will handle, for example, if you had 2.5 on your machine but another machine only had 2.4 - would .NET bind to the 2.4 version happily or will it only bind from earlier versions to later versions of an assembly (e.g. compiled against 2.4, but 2.5 availale at runtime?)