Conversation

I found myself debugging some XML for an external service and found it very difficult doing a spot-the-difference on a huge wall of text.

This will popup opendiff against all the registered stubs and the attempted request.
Tried out and working on my mac.
Apart from tests would you recommend anything else?
Perhaps a better way to configure the diff tool, and make it switchable?
Any other points?

This comment has been minimized.

Very cool idea with using the diff tool to spot the differences. It can be very useful in some circumstances.

I'm not sure webmock should depend on any external tools, but I can see you made it configurable, so it's an option.

Maybe it would be better to declare a need to use diff tool as webmock configuration. I.e WebMock.use_diff_tool or something.
Then this could be added temporarily in the test you're trying to debug, instead of enabling it for all test with env variable.
I don't think I would use this functionality for more than one test at once, since I wouldn't know which diff window is from which test.

I'm not sure the diff tool should be initialized within exception constructor. I would rather imagine that the exception is
independent and it has to be intercepted somewhere to initialize the diff tool.

If I have 5 stubs declared, it is going to open 5 windows at once, right? Did you test it with just one registered stub or many?

Very cool idea with using the diff tool to spot the differences. It can be very useful in some circumstances.

I'm not sure webmock should depend on any external tools, but I can see you made it configurable, so it's an option.

Maybe it would be better to declare a need to use diff tool as webmock configuration. I.e WebMock.use_diff_tool or something.
Then this could be added temporarily in the test you're trying to debug, instead of enabling it for all test with env variable.
I don't think I would use this functionality for more than one test at once, since I wouldn't know which diff window is from which test.

I'm not sure the diff tool should be initialized within exception constructor. I would rather imagine that the exception is
independent and it has to be intercepted somewhere to initialize the diff tool.

If I have 5 stubs declared, it is going to open 5 windows at once, right? Did you test it with just one registered stub or many?

This comment has been minimized.

Thanks for your comments.
I've been using it for a few days now and so far it has saved me a lot of time.
I think it might be nice to configure it for certain headers too.

I.e. in my case only fire up for "application/xml"

It's a pain as it actually opens up windows which block the thread at the moment, so I'd like to tackle that issue too.
And yes it does open up windows for each stub and for each test failure.
It's actually not hard to tell which ones are related because of the visual diffing.
And It's still easier than comparing them in the terminal.

My first attempt was trying to parse and diff the xml tree but this approach is more pragmatic.

I'll take a look at your points and incorporate them and get back to you with an updated pull request.

Thanks for your comments.
I've been using it for a few days now and so far it has saved me a lot of time.
I think it might be nice to configure it for certain headers too.

I.e. in my case only fire up for "application/xml"

It's a pain as it actually opens up windows which block the thread at the moment, so I'd like to tackle that issue too.
And yes it does open up windows for each stub and for each test failure.
It's actually not hard to tell which ones are related because of the visual diffing.
And It's still easier than comparing them in the terminal.

My first attempt was trying to parse and diff the xml tree but this approach is more pragmatic.

I'll take a look at your points and incorporate them and get back to you with an updated pull request.

This comment has been minimized.

I should imagine it being as useful for json.
I haven't had any test failures in the json parts of my app, which I think says something.
I prefer using json when I can as it's easier to spot the differences yourself anyway :-)

Another approach which would be less intrusive (but more work), would be to do some nice diffing and colouring in the terminal output.
In fact it might help at the moment just to change from the default red output to different colours for the messages, stubs and output.

Another improvement to the output would be optional Ruby 1.9 hash syntax in the example stubs.

I should imagine it being as useful for json.
I haven't had any test failures in the json parts of my app, which I think says something.
I prefer using json when I can as it's easier to spot the differences yourself anyway :-)

Another approach which would be less intrusive (but more work), would be to do some nice diffing and colouring in the terminal output.
In fact it might help at the moment just to change from the default red output to different colours for the messages, stubs and output.

Another improvement to the output would be optional Ruby 1.9 hash syntax in the example stubs.

This comment has been minimized.

I'm actually going to close this pull request as I've no immediate need to introduce this functionality and so don't intend to put the time in to do the necessary cleanup. I have found that complementing WebMock with https://github.com/myronmarston/vcr solves my issue in a human-friendly way.

I may reopen if I decide to clean up the code. Thanks for the comments.

I'm actually going to close this pull request as I've no immediate need to introduce this functionality and so don't intend to put the time in to do the necessary cleanup. I have found that complementing WebMock with https://github.com/myronmarston/vcr solves my issue in a human-friendly way.

I may reopen if I decide to clean up the code. Thanks for the comments.