On 15 November 2017 at 00:14, Richard Sargent <rsarg...@5x5.on.ca> wrote:
> >> 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. > Or it could go to Amber, half-way between green & red to mean probably correct. cheers -ben > > > 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. > > > ------------------------------ > *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On > Behalf Of *Tim Mackinnon > *Sent:* November 14, 2017 06:19 > *To:* Any question about pharo is welcome > *Subject:* Re: [Pharo-users] Why does the test runner show red when I > correct a test? > > 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.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@gemtalksystem >> s.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> >> 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 >>> >>> >> > >
