On Fri, Nov 10, 2017 at 08:12 Richard Sargent < richard.sarg...@gemtalksystems.com> wrote:
> I think it is correct because icon shows the last run state. >> > My claim is that is not a true statement. > > > Then it is up to user to check how test is working in normal way. >> > This is my point. You must do this or you cannot know. > > The first statement should say "the last run state from the point of > interruption". Any changes made in the code after the interruption > invalidate your knowledge of the correctness of the code leading up to that > point. > > 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. > +1 > > Many people in our industry, our profession have a disturbing tendency to > be vague and practice self-deception. Take the concept of a "bug"as an > example. They don't "fly into" our code; we *put* them in it. *We* put them > in. That's why they should be called errors or defects. > > Likewise, claiming that a test that failed run successfully and > uninterruptedly to completion "succeeded" is a fallacy. In general, the > test runner cannot make that claim. It lacks the knowledge to do so. > > On Fri, Nov 10, 2017 at 1:21 AM, Denis Kudriashov <dionisi...@gmail.com> > wrote: > >> Hi Richard >> >> 2017-11-09 23:51 GMT+01:00 Richard Sargent < >> richard.sarg...@gemtalksystems.com>: >> >>> I think it is correct to show green if you fix your problem in the >>>> debugger and then proceed and it passes all assertions. But it should >>>> equally fail if you proceed and it asserts false or craps out. >>>> >>> >>> It would be a lie. The truth is only that from that point on, it is >>> correct. You have no guarantee that your correction hasn't broken something >>> that would occur in the next run prior to the point at which you applied >>> the correction. >>> >> >> I think it is correct because icon shows the last run state. It is not >> depends on the way how user manages to pass or fail the test. >> So user can hack the test from the debugger and make it pass or fail >> using inspector, scripting or whatever interaction with available objects. >> When he closes the debugger (by proceed or window close) it is expected to >> see the result of this hacking in the UI. So test icon should be updated >> accordingly. >> Then it is up to user to check how test is working in normal way. >> >> >>> >>> Hence my assertion that you cannot determine the colour until the next >>> run. >>> >> >> >> >>> >>> >>> On Thu, Nov 9, 2017 at 2:47 PM, Tim Mackinnon <tim@testit.works> wrote: >>> >>>> Thanks Denis - I'll try my simple TDD test case in Pharo 7 (I haven't >>>> tried it yet - probably time to). >>>> >>>> I think it is correct to show green if you fix your problem in the >>>> debugger and then proceed and it passes all assertions. But it should >>>> equally fail if you proceed and it asserts false or craps out. >>>> >>>> Strange it would vary in 6.1 - but I'll check. >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>> >>>> >>>> Sent from my iPhone >>>> On 9 Nov 2017, at 19:54, Denis Kudriashov <dionisi...@gmail.com> wrote: >>>> >>>> In Pharo 7 it works. >>>> >>>> 2017-11-09 18:29 GMT+01:00 Tim Mackinnon <tim@testit.works>: >>>> >>>>> Thanks for looking at this - there is an issue however - when you >>>>> apply that change (at least in a Pharo 6.1 image) - it shows green even >>>>> when a test fails? So I think its turned one problem into the opposite >>>>> one. >>>>> >>>>> Unfortunately I haven’t got a chance to look a bit deeper to help - >>>>> but it might be worth rolling back this change for now. We should fix it >>>>> though - and the answer must be in the area you have identified. >>>>> >>>>> tim >>>>> >>>>> On 9 Nov 2017, at 12:43, Denis Kudriashov <dionisi...@gmail.com> >>>>> wrote: >>>>> >>>>> And now it is in latest Pharo >>>>> >>>>> 2017-11-09 12:16 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: >>>>> >>>>>> Hi Tim. >>>>>> >>>>>> Fix is here >>>>>> 20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed >>>>>> <https://github.com/pharo-project/pharo/pull/456> . >>>>>> Thank's for reporting. It forces me to fix. I always noticed it but >>>>>> never take it seriously :) >>>>>> >>>>>> 2017-11-09 11:32 GMT+01:00 Tim Mackinnon <tim@testit.works>: >>>>>> >>>>>>> Hi - I really like the build in test runner in the Pharo browsers, >>>>>>> and I was preparing a talk to show how great TDD is in Pharo and how we >>>>>>> aren’t ashamed of our debugger when testing (it augments the experience >>>>>>> in >>>>>>> fact - letting you poke around and get your thoughts straight). >>>>>>> >>>>>>> However - if I pick rerun in the test runner debugger - and step >>>>>>> through a test and then correct the failing code, and hit resume - the >>>>>>> browser always shows a red failure, even though the execution is now >>>>>>> correct. I have to run the test again. >>>>>>> >>>>>>> This doesn’t seem right to me - are we missing a success event or >>>>>>> something? >>>>>>> >>>>>>> >>>>>>> Tim >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >
