Each time I run a test using TestDriven, it creates another "rocket" icon on my system tray. I have to manually do right-click Quit to get rid of them. How can I avoid this?
Check for any open file handles you may be creating in your tests. Depending on the size of your test suite that may be too time consuming and tedious. There's an option to turn off caching the test process between test runs in the options for TestDriven.Net. This seems to be designed for instances like what you're seeing. From their documentation:
Cache test process between test runs
By default the external test process will be cached when the ‘Run Test(s)’ command is used. This process appears in the tool tray as a rocket icon which can be used to kill the process. This is fine unless one of your tests starts leaking leaking native resources (such as leaving open a file handle). The best solution is to fix the resource leak, but you now have to option to work around the issue by killing the test process at the end of each test run. This can be useful if the resource leak is in a 3rd party DLL which can’t be easily be changed.
From here: http://weblogs.asp.net/nunitaddin/archive/2008/12/03/testdriven-net-options-pane.aspx
I realize you asked this a year ago, so you may have already figured out a way to fix the problem. In that case, I would ask that you let us know what you did.
Related
P.S.: No, I do not want to debug my script. It is pretty awesome.
The problem is the application under test. If I place a few orders, it crashes. So what I want to do is: mid-execution, when I see that the application is crashed, I want to pause the test script, bring the application back up and running, and then resume the test.
I know that this is not the point of time when I should be running the test scripts as the application is not stable enough, but the developers are working on it and hopefully soon enough, they will fix it. I am just curious to know if there is a solution, because I couldn't find one. Of course I could've integrated bringing the application up again when it crashes in my tests, but that is not what I want to do.
My system:
OS: Linux Mint
Tests: Watir (Ruby) + Cucumber on Chrome
I run the tests on linux terminal using cucumber tags.
I just want to know in general if there is any way to pause and resume execution. For example, when I want to stop all the tests, I give the command line interruption Ctrl + C. So is there any such interrupt command to pause and resume?
Okay, since you want a "general" answer, here goes...
Based on your context, you are looking for a "crashed" condition in your project.
My own approach to solving this problem would involve writing a helper method that would look for this condition and, if true, it would "pause". For example...
def pause_if_crashed
sleep 30 if #browser.product_price.nil?
end
Then I would sprinkle this helper method in likely "crash" spots in my other functional methods.
Without more specifics about your needs, this is about as helpful as I can get, I think.
As we trying to make more frequent builds (and as our site traffic has increased), we've noticed that during higher traffic, the initial post-build page loads spike to 20 or 30 seconds. Our builds are published by copying DLL's + PDB's to a single server which is sync'd to one other server. That file-copy generally takes a few seconds.
What are some contributing factors to this sort of initial latency spike? Are there any commonly taken steps to avoid this problem? (I can't imagine high-traffic site that perform multiple builds/day, if not multiple builds/hour, tolerate this sort of thing.)
The main cause of this delay is ASP.Net doing compilation on the pages during first load, transforming the aspx markup into code.
You can solve this (and is actually listed as the first advantage on this link) by doing a pre-compile during your build. Of course, the trade off to this is longer build times. More information is here: http://msdn.microsoft.com/en-us/library/bb398860(v=vs.100).aspx
If you're using MSBuild to handle your CI builds by using the AspNetCompiler task in MSBuild: http://msdn.microsoft.com/en-us/library/ms164291.aspx
Another advantage this has (And why I tend to use this even in development builds), is if you integrate this into your build process, and you end up with syntax errors on a page, the build will fail, instead of your users being the first one to catch it.
In response to your comment (my response was getting too long for a comment):
Actually, I wasn't even aware of the batch settings myself until now. It looks like setting batch to false makes sense during development to reduce initial load times there. But, it seems that doing so would make asp.net function in assembly-per-page mode, which can slow things down on larger apps. So, probably the best compromise would be in development environments, set batch to false to speed up development time, then use the web.config transforms to set it back to true for production, and use the pre-compiler during the production build. Then you'll only pay the pre-compilation costs once for both servers, and in a way that's not visible to users.
I have created tests using selenium 2, I'm also using the selenium standalone server to run the tests.
The problem is that if I run one test, it works. If I run multiple tests, some of them fail. If I try then to run a failed test, it works.
Could the tests be running on threads?
I've used the NUnit GUI, and TeamCity to run the tests ... both give the same results : different tests fail, run again, other tests fail.
Any thoughts ?
EDIT
The tests shouldn't depend on one another. The database is emptied and repopulated for every test.
I guess the only problem could be that the database is not emptied correctly ... but then if I run the same test multiple times it should also fail.
EDIT2
The tests fail with "element not found".
I'll try and add a "WaitForElement" that retries every few milliseconds and maybe that will fix it.
Without knowing the exact errors that are thrown its hard to say. The normal causes of flakiness tend to be waits are not set to a decent time or the web server can't handle that many requests.
If the DB is on the same machine as the webserver, and why shouldnt it be on a build box, it can be intensive to clear it out.
I would recommend going through each of the errors and making it bullet proof for that and then moving to the next. I know people who run there tests all the time without flakiness so its definitely an environmental thing that can be sorted.
I know I'm a bit late to the party here but are you using a single window to run your tests? I had a similar issue since the site I'm testing has only one page load event so waiting for elements or pausing the test became very dodgy and I had different tests passing each time. Adding a ton of wait times didn't work at all until I just opened a new "clean" browser for each test. Testing does get slower but it worked.
I'm fairly new to web service development, and I am really confused about how ASP.Net Development Server synchronizes with code during debug mode. When I make changes to my service, I cannot figure out how to propigate those changes so that my client can "see" them (I've been able to synchronize through a stumbling series of publishing the service, viewing the service in browser, etc... but I have a feeling there's a more reliable system than my random ritual).
Here are the symptoms I'm seeing: After I've made a change to the code behind my service (Service1.svc.cs), started the application through the debugger and attached the debugger to the WebDev.WebServer.exe process as well, my latest changes are not executed, and my breakpoints are not hit (they have the message that
"The source code is different from the original version."
What really baffles me, though, is that when the ASP.Net Development Server notification pops up in my system tray, its physical path points to my project folder, so I don't understand how it could be looking at anything but my current code files.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
I was wondering is there is a fool-proof way to run a program on windows such that I'm guaranteed that no interactive dialogs of any kind are displayed.
I've tried the registry ErrorMode hack, calling _CrtSetReportMode(), etc., but they all have holes in them or require you to modify the program.
I need a way to run an arbitrary program and practically force Windows to execute them such that there is no possibility for them to open a window. It is perfectly ok for the program to crash if it attempts to open a window.
Would running the program as a service solve the problem?
I'm not aware of any other ways that might possibly work. Running as a service won't solve the problem either as the dialog will be displayed on the service's desktop, which you generally don't have access to.
You could use a library such as Detours to intercept all calls to functions that might display a dialog box (this might in fact be nearly everything in user32.dll).