On Wed, Dec 2, 2015 at 9:02 AM, Juraj Kubelka <juraj.kubelka(a)gmail.com>
wrote:
Hi,
On Dec 1, 2015, at 17:47, Andrei Chis <chisvasileandrei(a)gmail.com> wrote:
Hi Mariano
On Tue, Dec 1, 2015 at 12:59 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:31 AM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
On Tue, Dec 1, 2015 at 1:05 AM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
Uhhh that's very cool. Quick question, what
happens if the textual
representation of the actual vs expected is the same yet the objects are
not #= ?
It shows no diff and then I must go to see the inspector?
These textual representations can be customized per each object type,
however if they are the same now it just shows the diff pane with no
differences.
Another idea would be to also show two inspectors side-by-side apart
from the diff.
A side-by-side inspector would be another really cool addition for when
the string comparison won't work.
Then even if you see or not a difference in the
textual diff, you could
use the inspector to look at differences between the state.
Also right now the diff is textual. Adding better diff widgets for
specific data types would help.
Oh yes. But I think that adding a side-by-side inspector would be a great
second step in which you know you can always fall back no matter which kind
of object.
I added two side by side inspectors. I still need to improve/disable
navigation in these embedded inspectors
<debugger.png>
BTW...since we are near Christmas... it would be terrific to have a
button somewhere to show/hide the #setUp method besides the code
representing the piece of stack you clicked. Sometimes when I am debugging
test failures that had a setup I always have to open another window with
the setup because I don't remember everything I did there and that's useful
information to understand what a test could have failed. There was a
Nautilus plugin for that some time ago.
Sounds like an useful feature. I'll give a try implementing it. Or if you
are faster you can give it a try :)
I like the idea. Maybe having a ‘setUp tab; next to ‘Source’ tab whenever
we browse a test case object in debugger? Or it could be part of the
inspector the same way you did ‘Diff’ tab.
I think the MAIN point for me is to be able to see the setUp AT THE SAME
time with the code of the failing error. If I have to click another tab to
see the setup and then another click to go back to see my test, then I gain
nothing. Maybe splitting (either vertically or horizontally) the area where
now you see the method source (of the selected stack) in order to also see
(fixed) the setUp ? Or .. maybe a new tab in the below (expected vs
current, etc) called "setUp". That way, at least I can see the method and
the setUp all together (Ok, I cannot see the expected vs current, but ok)
Cheers,
Juraj
Cheers,
Andrei
Cheers,
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev