Richard - I better understand what you are saying now. If you change the method and save it (hence restarting on the stack) I would expect it to turn green if I press resume. That is the TDD flow I expect, and one which sunit and coding in the debugger was predicated on.
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. Tim > On 10 Nov 2017, at 19:45, Richard Sargent > <richard.sarg...@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 > <mailto: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.sarg...@gemtalksystems.com > <mailto:richard.sarg...@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 <s...@clipperadams.com >> <mailto:s...@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 >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> >> >> >
