I am trying to work on whats wrong with my lithium current setup. I have installed the Xdebug and verified that remote host can establish the connection as requested.
http://myinstance.com/test/lithium/tests/cases/analysis/logger/adapter/CacheTest?filters[]=lithium\test\filter\Coverage
Please note in fresh installation in local environment , "Coverage" Filter is working as expected.
I added some test code inside the "apply" function in coverage.php but it is not even called !!!! Can some have experience in debugging the above URL ?
I am not able to understand why coverage filter is not called up and executed ...Any hints are highly appreciated !
The filters in the query string are added to the options in lithium\test\Controller::__invoke() and then passed into the test Report object created by the test Dispatcher. The Report object finds the test filter class and then runs the applyFilter() method for that test filter as can be seen in lines 140 to 143 of the current code. So those lines would be another place to debug. Those should wrap the run() method of your tests with this filter code inside the apply() method that uses xdebug_get_code_coverage() and related functions. You said you added test code in the apply method and it isn't called. I'm not sure what the issue is. Are you sure you are pointing to the right server and code location? It is possible to run tests from the command line. Maybe you should try that. See code comments in lithium\console\command\Test or run li3 test --help for info on how to use the command-line test runner.
I can confirm on nginx I also have /test/lithium/tests/cases/analysis/logger/adapter/CacheTest?filters[]=lithium\x5Ctest\x5Cfilter\x5CCoverage in my access log. The \x5C is expected url encoding of the backslash character.
Every once in awhile, in ways that seem unpredictable to me, the code line
if not CDS.Locate('Name',aName,[]) then ...
resolves true (i.e., cannot find the string aName in the field 'Name') even though I know there is a record. I can close and reopen the application, load the exact same file, run the exact same command--repeat all my actions, in other words--and have everything work as expected the next time through. And the time after that. I can even just reopen the same file, and the code will run as expected ... I don't know what the issue is and, frankly, with something intermittent like this I don't even know where to look!
Any thoughts about where to start? ...
In delphi XE7 there is a serious problem TClientDataSet.Locate and it does not work with some fields look at QualityCentral [127703]
This is a long standing source of frustration, but maybe there is something I'm missing. If i'm in the middle of debugging, and I want to exit the debugger and return to IRB or Rails Console, "quit" won't work as it will exit IRB. "finish" also seems to have the same effect as continue. Using "delete" to remove breakpoints and then trying "continue" or "finish" doesn't work.
Any ideas?
At least in byebug, you can do this:
eval return
Which has the net effect of evaluating a return statement from the current function. That works sometimes, depending on how the call stack looks.
Now while this doesn't remove the current breakpoint .... if you just want control back, this will do that in most cases, depending on how your code is structured.
It also is useful to do this when creating a debug entry in your code:
byebug unless $continue
So if all else fails in a debugging session, you can always run
$continue = true
c
Now this opens up a whole set of possibilities.
This SO question has a few good suggestions. It deals with specifically with debugging inside of loops. One great solution is to set the break point outside the loop, then from irb set it inside the loop and clear it manually when you want to.
Basically it comes down to putting a little bit of thought into where you set your breakpoints.
Other than that there doesn't appear to be anything else you can do.
Sometimes I need the parameter to be appended, instead of overriding the one in configuration:
for instance
mvn test -DargLine="-Dportal.test=huge"
should be added to
<argLine>-XX:+CMSClassUnloadingEnabled</argLine>
so the result would equal to
<argLine>-XX:+CMSClassUnloadingEnabled -Dportal.test=huge</argLine>
Could please anybody tell me if it is possible and how ?
EDIT: Please don't answer with " Why would you want to do that" kind of annoying questions.
I have never used argLine but maybe this is what you are looking for.. i.e.:
<argLine>-DskipTests=true ${argLine}</argLine>
(I used skip tests as an example :))
I just caught myself doing something I do a lot, and wanted to generalize it, express it, share it and see who else is following this general practice, to find some other example situations where it might be relevant.
The general practice is getting something wrong first, on purpose, to establish that everything else is right before undertaking the current task.
What I was trying to do, specifically, was to find examples in our code base where the dojo TextArea widget was used. I knew (because I had it in front of me - existence proof) that the TextBox widget was present in at least one file. So I looked first for what I knew was there:
grep -r digit.form.TextBox | grep -v
svn
This wasn't right - I had made a common (for me) mistake of leaving off the star, so I fixed that:
grep -r digit.form.TextBox * | grep
-v svn
which found no results! Quick comparison with the file I was looking at showed me I had misspelled "dijit":
grep -r dijit.form.TextBox * | grep
-v svn
And now I got results. Cool; doing it wrong first on purpose meant my query was correct except for looking for the wrong thing, so now I could construct the right query:
grep -r dijit.form.TextArea * | grep
-v svn
and be confident that when it gave me no results, it was because there are no such files, and not because I had malformed the query.
I'll add three other examples as answers; please add any others you're aware of.
TDD
The red-green-refactor cycle of test-driven development may be the archetype of this practice. With red, demonstrate that the functionality doesn't exist; then make it exist and demonstrate that you've done so by witnessing the green bar.
http://support.microsoft.com/kb/275085
This VBA routine turns off the "subdatasheets" property for every table in your MS Access database. The user is instructed to make sure error-handling is set to "Break only on unhandled errors." The routine identifies tables needing the fix by the error that is thrown. I'm not sure this precisely fits your question, but it's always interesting to me that the error is being used in a non-error way.
Here's an example from VBA:
I also use camel case when I Dim my variables. ThisIsAnExampleOfCamelCase. As soon as I exit the VBA code line if Access doesn't change the lower case variable to camel case then I know I've got a typo. [OR, Option Explicit isn't set, which is the post topic.]
I also use this trick, several times an hour at least.
arrange - assert - act - assert
I sometimes like, in my tests, to add a counter-assertion before the action to show that the action is actually responsible for producing the desired outcome demonstrated by the concluding assertion.
When in doubt of my spelling, and of my editor's spell-checking
We use many editors. Many of them highlight misspelled words as I type them - some do not. I rely on automatic spell checking, but I can't always remember whether the editor of the moment has that feature. So I'll enter, say, "circuitx" and hit space. If it highlights, I'll back up over the space and the "x" and type another space - and learn that I spelled circuit correctly - but if it doesn't, I'll copy the word and paste it into a known spell-checker to see whether I did.
I'm not sure it's the best way to act, as it does not prevent you from mispelling the final command, for example typing "TestArea" or something like that instead of "TextArea" (your finger just have to slip a little for such a mistake).
IMHO the best way is to run your "final" command, but on two sample files first : one containing the requested text, another that doesn't.
In other words, instead of running a "similar" command, run the real one, but over "similar" data.
(Not sure if this would be a good idea to try for real!)
For example, you might give the system to the users for testing and tell them the password to get started is "Apple".
You know the users are fully up and ready to test (everything is installed and connections to databases working) when they contact you and say the password doesn't work (it's actually "Orange").