Feature: Assert object should have pass/fail return value

[BluejacketScott]

This would allow for logging a test run (to a text file or some such) with the name of the test and a pass/fail flag instead of returning void. This would really help with integrating into an issue tracking system or allow devs to trace what's failing and perhaps watch for regressions.

[Vogel612]

The test-explorer already supports copying the results of a test-run. It's not really useful to add these return values when Rubberduck can already export what you're looking for into XML, html, csv and Rich Text

[BluejacketScott]

It doesn't work though.

[Vogel612]

The solution is to fix the bug, not implement a new feature that works around the bug :)

[BluejacketScott]

Agreed. Thanks.

[BluejacketScott]

I know you closed this ticket and for good reason, but I would like to see if you'd be willing to reconsider giving us programmatic access to a return value on the Assert object. I am struggling to trace a failure and I think it's because I have interdependent tests so looking at a run log would be very helpful to track it down. It would also permit devs to run automated scripts against the log. Having to copy/paste the results is a manual task that should be automate-able.

[retailcoder]

I hear you. In the .net world a failing Assert throws an exception, so you get a stack trace. We could make them throw a trappable run-time error (on top of the current behavior, i.e. handling the error wouldn't affect the test outcome).. but returning a value and executing conditional logic based on that seems like a wide-open door for abuse IMO. There must be a reason no testing framework implemented asserts that way...

[BluejacketScott]

Oh, an exception would work beautifully!