>> I would expect it to turn green if I press resume.

I disagree with your expectations. You are arguing that we should operate is if "probably correct" is the same as "correct". That's why we have ****ty software.

I have no objection to leaving the method uncoloured when you resume after correcting the error.

I have no objection to eliminating the red colouring in these scenarios.

I strongly object to pretending that it is known to be correct.

In my experience, we end up with better results when we act on what we absolutely know to be factual and stop relying on guessing.

However, there is the potential that some memory object that cached a result and is now running a second time could be the cause of a pass and so it is remotely possible that this is a false pass…. (And this I think is the crux of your argument - if any memory object is affected, theoretically you should rerun the whole transaction from a virgin state - which is effectively rerun the test from the beginning). So I guess we are discussing that we don’t have fully transactional memory executions?

However I would argue that its way more common that you edit a method and fix a text and have 0 side effects than mucking around in memory or having something that rerunning locally messes up memory as well. So its much more useful to get the confirmation of green and move on. YES you could have a subtle error, and when you re-run it may later go red - but I would favour the 99% case as its a annoying if you are doing TDD.

On 10 Nov 2017, at 19:45, Richard Sargent <richard.sargent@gemtalksystems.com> wrote:

I hear you and I understand your pain.

However, if you corrected the problem, not by a code change, but by playing in the object's inspector or otherwise causing its internal state to change, and then resumed from the debugger, would you still claim the method was successful and should be coloured green?

The only thing we can claim is that there were or were not further errors in the test. Colour it red if there were, but you cannot honestly colour it green. The code doesn't actually work.

On Fri, Nov 10, 2017 at 11:29 AM, Tim Mackinnon <tim@testit.works> wrote:

My specific usecase is from a pragmatic TDD perspective - failing test, in the debugger you fix the test and press proceed - expecting green. Getting red, and then immediately running again to get red takes away from our story of love coding and loving your debugger - and even Cassie me to mistrust the tools.

I get the idea that you can jiffy in the debugger and cause a false pass - but I feel you are penalised for doing it right at the moment.

Of course these tests will get run again, but I like the idea that if I did it right, it should recognise this, not incur an extra click and moment of doubt.

A button to rerun the whole lot, or automatically rerun, or just run it would work for me.

Tim

Sent from my iPhone

On 10 Nov 2017, at 17:56, Richard Sargent <richard.sargent@gemtalksystems.com> wrote:

That would be fine.
The point is that, without running the test in its entirety, from start to finish, without interruption, error, or failure, one cannot claim success.

On Fri, Nov 10, 2017 at 9:34 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:

Richard Sargent wrote
> The only reliable conclusion one can make from such an interrupted run is
> whether it failed again. So, it would be possible to determine that the
> test should be coloured red, but it is impossible to *reliably* claim that
> the test should be coloured green.

What if we ran the test again as if from the browser/runner before setting
the icon?

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html