Recently my company upgraded from RFT 8.1.1.1 to RFT 8.2 and now all of our rational_ft_log.txt files that get generated from tests are at least a dozen times longer than they were before we upgraded.
These files are so much longer now because every little "getProperty on frame" that happens returns a +++Pass, like this:
++ PASS 30-Mar-2011 11:15:43.113 AM getProperty on the Frame
line_number = 50
script_name = DebugCommands.IR2_18_DebugCommands
Anyone know how to get rid of these nasty things?
I have searched exhaustively for RFT options to change, and I have looked a little into writing a plugin to output log files. I can't seem to get IBM to get back to me.
You could write your own plugin, or just create your own custom logging methods in a super helper class. I do that anyway, to give me flexibility to output my logging info to any destination. But to answer your specific question about getting rid of the extraneous getProperty log messages, see the RFT info center:
Logged events such as verification
point failures, script exceptions,
object recognition warnings, and other
additional playback information are
displayed in the playback log results.
From Rational® Functional Tester
version 8.2 and later, the results of
the getProperty() command are also
displayed in the log results. If you
do not require the log event to be
displayed in the playback log, you can
disable the event in the log results.
Before you begin: Ensure that you have
access to modify the ivory.properties
file.
About this task: To disable the
getProperty() log event, you must
modify the ivory.properties file.
Procedure: Open the ivory.properties
file available in the \Functional
Tester\bin\ directory. Add the
following line of code at the end of
the file
contents:rational.test.ft.log.enhanced=false
The fix is available under PMR29716. However, you would have to upgrade RFT8.2 to RFT 8.2.0.1 iFix01 to see it working.
Check the PMR # https://www-304.ibm.com/support/docview.wss?rs=0&uid=swg24029194
Related
We have a test suite that runs 30 or more minutes and it is not uncommon for me to see a situation like this:
I don't generally want to break on a first failure (--stop-on-failure) but in this specific example, I also don't want to wait another 10-15 minutes for the test suite to finish. If I do Ctrl+C, the process stops immediately and I won't see any messages.
I'm specifically interested in the format that PHPUnit uses in the console which I find very useful. For example, logging to a file using --testdox-text produces a nice but not very detailed list. Logging with --log-teamcity is verbose and quite technical.
Is there a way to see "console-like" PHPUnit messages before the test suite fully finishes?
Update: I've also opened an issue in the official repo.
maybe you could register a listener in your phpunit.xml file and implement its addFailure() method to display some info in console or a file...
A Qt project gives a number of errors - that I do not actually consider errors I think:
Some examples:
Fontconfig error: "/etc/fonts/conf.d/65-khmer.conf", line 32: out of memory
// ?
QGraphicsItem::ungrabMouse: not a mouse grabber
// i think happens when the mouse grab didn't quite happen, user moved too fast...
A few others
the first one seems it has an answer here https://askubuntu.com/questions/421891/fontconfig-error-out-of-memory
So I cannot fix it through software, the user must fix it... since it is system dependent...
Even built in release, these errors will still show up on command line... Since they do not cause the application to behave abnormally, I don't think the user should see them.
How can I build/deploy the application without these errors showing ?
ideally of course there would be no errors in a deployed application, but I don't know what I can do about those types of errors...
It is possible to redirect a stream (in this case stderr) after the fact using
freopen("/dev/null", "w", stderr);
Just place this in your main before any other code runs and you should be good. Keep in mind that this might need more work on Windows.
If the error message is posted through the Qt Message infrastructure (qDebug etc.) you can set a new message handler through the function qInstallMsgHandler.
I'm running into a very weird issue. I have created 4 environments:
frontend_dev
frontend_prod
backend_dev
backend_prod
In frontend_dev, the profiler is shown at the bottom of the page as it should be. However, on the backend_dev environment it is not shown. Upon investigation I have found out that the piece of code to load the profiler is actually there at the body end tag, however the call to get the profiler content doesn't return anything at all.
Further investigation showed that the loadProfile method failed because $this->storage->read($token) returns NULL.
I wonder what is happening, seems like somehow the storage couldn't save the profile and thus could not read it upon request?
Edit 1:
I think I know why: previously both my frontend and my backend were using the same environment (dev) and the profiler cached the toolbar content to the same place. However, now that we are using 2 environments the profiler caches the toolbar content to backend_dev but attempts to load from frontend_dev cache folder.
I have found the reason as described above, in the end for the sake of simplicity (and also other reasons) I have separated my original app into 2 apps using this guide
So far it has worked out very well for me.
A lot of time can pass between the moment a stack trace is generated and the moment the stack trace is thoroughly investigated. During that time, a lot can happen to the file in question, sometimes obscuring the original error. The error might have been fixed in the meantime (overlapping bugs).
Is it possible to get Stacktraces that show the offending file at the time of the error?
Not elegantly, and you normally don't want the user browsing through code that's throwing unexpected exceptions anyway (open door to an attacker).
Usually, what happens in a dev shop is that the user reports an error, stack trace, and the build it occurred on. As a tester, you can grab that build from your archives (you ARE keeping an archive of all supported releases somewhere handy, RIGHT?), install, run, and try to reproduce the error, working with the user to provide additional info as necessary. I've seen very few bugs that couldn't be reproduced EVENTUALLY, even if it required running the program against a backup of the user's production database to do it.
As a developer, you can download that build's source code from your version control repository (you ARE using version control, RIGHT?), and examine the lines in the stack trace to try to discover the problem by inspection, and/or build and run it to reproduce the error. Then, you go back to the latest source version, build, and run the same steps (a UI automation system can help out here), and if you don't get the error, someone else already found and fixed it. If you still get the error, you also got an updated stack trace with lines that match the current build, allowing you to set your breakpoints and step through.
What KeithS said, plus there are ways to capture more helpful state information at the time of the Exception using the Exception.Data property. See http://blog.abodit.com/2010/03/using-exception-data-to-add-additional-information-to-an-exception/
While KeithS' answer as pretty much correct, it can be easier and more elegant than you think. If you can collect a dumpfile (instead of just a stack trace), you can use a Symbol Server and Source Server in combination with your debugger to automatically pull your correct-version code from source control.
For example: if you enable PDB output and source-server integration in MSBuild, and upload the resulting PDBs to a symbol server, Visual Studio can automatically load the correct source control from a TFS or SourceSafe repository based on the information in a minidump.
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.