Ben, I think you understand the dilemma.
My philosophy is to avoid claims that are known to be not provably true.
i.e. don't colour it green, because the test runner cannot claim that
knowledge.
I am agnostic to whether it should be left uncoloured or coloured red to
document the fact that it
On 16 November 2017 at 00:20, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:
> I think that setting the button back to gray is a good behaviour.
>> - it is the same thing that happens once you modify a method (which is
>> what is happening during debugging)
>> - it explicitly says
BTW I like grey for a method that was edited in the debugger.
Because red is not good. The proof is that when I rerun my test is green.
While saying I do not know you have to rerun is a good solution.
I like it.
I got always frustrated with the red.
On Fri, Nov 24, 2017 at 12:05 AM, Stephane
Hi andrew
I like your idea.
It is fun and at least we can spot test.
Now sometimes we will have to have self assert: true because running a
code can be also considered as a test.
Now what I do not like is empty test method because there are green.
stef
On Tue, Nov 21, 2017 at 10:07 PM, Prof.
A test that asserts nothing has only asserted that the code ran through
without throwing an error. :-)
I like your proposal that such a test is an inherently failing test.
(Of course, that will result in the student adding a single assertion at
the end, of the form "self assert: true"!)
On
While we are discussing colors, what should we do about a test that does not
make any assertions at all?
A couple of years ago, a smart student who was working on a testing dialect for
me decided that such tests should be in a new category all of their own. Later
I simplified things and just
I would agree that grey is better than red - but I personally think we’re being
too pedantic on this - particularly when doing TDD and coding in the debugger.
If I’m writing straight forward tests and like to see a red failure (either by
deliberately returning false, or a subclass
Richard Sargent wrote
> I would go a little further. Any method modified by the developer during
> the course of running a test voids the ability to claim the test
> succeeded.
> Likewise, for any object editted in an inspector.
That makes sense to me.
-
Cheers,
Sean
--
Sent from:
2017-11-15 17:16 GMT+01:00 Richard Sargent <
richard.sarg...@gemtalksystems.com>:
> And in this thread only Richard was against current logic.
>>
>
> I am against colouring it green without having run the test without
> interruption or error. I don't think that is the current logic.
>
Fix is
>
> I think that setting the button back to gray is a good behaviour.
> - it is the same thing that happens once you modify a method (which is
> what is happening during debugging)
> - it explicitly says "please rerun the test because you may have
> introduced side effects"
>
I would go a
>
> And in this thread only Richard was against current logic.
>
I am against colouring it green without having run the test without
interruption or error. I don't think that is the current logic.
On Wed, Nov 15, 2017 at 2:41 AM, Denis Kudriashov
wrote:
>
> 2017-11-15
On Wed, Nov 15, 2017 at 11:41 AM, Denis Kudriashov
wrote:
>
> 2017-11-15 11:08 GMT+01:00 Guillermo Polito :
>>
>> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov
>> wrote:
>>
>>>
>>>
>>> 2017-11-15 11:00 GMT+01:00
2017-11-15 11:08 GMT+01:00 Guillermo Polito :
>
> On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov
> wrote:
>
>>
>>
>> 2017-11-15 11:00 GMT+01:00 Guillermo Polito :
>>
>>> And just putting it back to gray? As "not run"?
On Wed, Nov 15, 2017 at 11:06 AM, Denis Kudriashov
wrote:
>
>
> 2017-11-15 11:00 GMT+01:00 Guillermo Polito :
>
>> And just putting it back to gray? As "not run"?
>>
>
> We can implement any logic.
> Personally I need current behaviour.
>
But it
2017-11-15 11:00 GMT+01:00 Guillermo Polito :
> And just putting it back to gray? As "not run"?
>
We can implement any logic.
Personally I need current behaviour.
>
> On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov
> wrote:
>
>> 2017-11-15
And just putting it back to gray? As "not run"?
On Wed, Nov 15, 2017 at 10:44 AM, Denis Kudriashov
wrote:
> 2017-11-15 1:49 GMT+01:00 Sean P. DeNigris :
>
>> Ben Coman wrote
>> > Or it could go to Amber, half-way between green & red to mean probably
2017-11-15 1:49 GMT+01:00 Sean P. DeNigris :
> Ben Coman wrote
> > Or it could go to Amber, half-way between green & red to mean probably
> > correct.
>
> Ha ha.
>
> Again, it seems that just automatically rerunning the test immediately
> after
> a human-manipulated run and
> On Nov 15, 2017, at 08:30, Richard Sargent
> wrote:
>
> I would say that is an entirely different question
You are right: this is a different scenario. But the suggested fix sounds like
a good one to me. After editing a test, even in the debugger, it
I would say that is an entirely different question. If a test isn't stable,
you have a completely different scenario from a test that interrupts
execution and is resumed.
On Nov 14, 2017 20:45, "Stephan Eggermont" wrote:
Op 15-11-2017 om 01:49 schreef Sean P. DeNigris:
Again,
Op 15-11-2017 om 01:49 schreef Sean P. DeNigris:
Again, it seems that just automatically rerunning the test immediately after
a human-manipulated run and setting the color based on that second run
addresses all points on both sides, no?
How many times do you want to restart execution? I have
>
> Again, it seems that just automatically rerunning the test immediately
> after a human-manipulated run and setting the color based on that second run
>
Absolutely!
(Although, I was kind of looking forward to the third colour discussions.
My vote would have been for paisley!)
On Tue, Nov
Ben Coman wrote
> Or it could go to Amber, half-way between green & red to mean probably
> correct.
Ha ha.
Again, it seems that just automatically rerunning the test immediately after
a human-manipulated run and setting the color based on that second run
addresses all points on both sides, no?
> *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 te
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
The CI sometimes fails due to heisenbugs, which of course we should fix but
mostly someone just kicks the CI off again and the test passes and the code
is integrated. So these heisenbugs slow down development when the CI
fails, and also we are not gaining any systematic statistics on where the
>
> So after a restart we would expect green
>
Yes.
Add having the test tool able to automate the tear-down and restart of the
test would be a good automation.
On Fri, Nov 10, 2017 at 11:41 AM, stephan wrote:
> On 10-11-17 18:56, Richard Sargent wrote:
>
>> That would be
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
On 10-11-17 18:56, Richard Sargent 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.
So after a restart we whould expect green
Stephan
Sorry "immediately running again to get red " should have been "to get green"
Tim
Sent from my iPhone
> On 10 Nov 2017, at 19:29, Tim Mackinnon wrote:
>
> immediately running again to get red
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
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.
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
wrote:
> Richard Sargent wrote
> > The only reliable
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
>
> 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
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
And give me concrete steps to see that it is not working (if you will find
it)
2017-11-09 23:47 GMT+01:00 Tim Mackinnon :
> 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
>
> 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
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
In Pharo 7 it works.
2017-11-09 18:29 GMT+01:00 Tim Mackinnon :
> 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
I saw this earlier and thought it was wrong to make that change. You cannot
assign a colour to the test if it does not run all the way through without
interruption. You cannot know whether it truly succeeded or not until you
finally run it all the way through without error or interruption.
Leave
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
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
42 matches
Mail list logo