[prev in list] [next in list] [prev in thread] [next in thread]
List: squeak-dev
Subject: Re: [squeak-dev] The Inbox: SUnit-cmm.116.mcz
From: Marcel Taeumel <marcel.taeumel () hpi ! de>
Date: 2019-05-31 8:28:29
Message-ID: 60ed24c2-e2c9-4450-8418-bbde30ee28bd () getmailbird ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Taking a look at the follwing, existing methods, everything seems to be alr=
eady there:
TestResult >> #failures
TestResult >> #failureCount
TestResult >> #defects
There is no need to change anything. The message #failures correctly combin=
es #unexpectedFailures and #unexpectedPasses. The message #defects combines=
#errors and #failures.
The use of the instance variables failures, errors, and passes is an implem=
entation detail that can stay is it is for this use case.
@Chris: Why did it matter that those instance variables refer to tests the =
current way?
Best,
Marcel
Am 30.05.2019 01:25:14 schrieb David T. Lewis <lewis@mail.msen.com>:
On Wed, May 29, 2019 at 04:07:11PM -0500, Chris Muller wrote:
> > > Would you mind helping me out with one then?
> >
> > What are the challenges exactly you are trying to tackle here? Can you =
provide more context?
>
> I had to think about this -- I think,
> abstractly, the case comes up when something that "should" (or "should
> not") work, is in conflict with whether we want it or expect it to
> work. We can look as close as the trunk image for a good example.
>
> SocketTest>>#testSocketReuse
>
> This test is expected to fail on Windows. For sake of argument, let's
> pretend that the reason is because there is a security hole in Windows
> (surely not! ;) ) and so we, as developers of Squeak, commented out
> windows support in the VM because we *absolutely positively want this
> to fail on Windows* until we're sure the coast is clear.
This is a test for platform-specific functions that are known to be
unavailable when running on a Windows VM. We expect it to fail when
running on Windows. SocketTest>>expectedFailures makes this explicit.
If Squeak is running on a Windows VM, this test will fail, and the
failure is expected. It is an expected failure.
That seems reasonable to me.
If it is not clear what an "expected failure" is, then a good method
comment in TestCase>>expectedFailures might help. And if we cannot
agree on the method comment, then it's a sure bet that we should not
be fiddling with the implementation.
Dave
[Attachment #5 (text/html)]
<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: \
Arial;color: #000000"> Taking a look at the follwing, existing methods, everything \
seems to be already there:<div><br></div><div>TestResult >> \
#failures</div><div>TestResult >> #failureCount</div><div>TestResult >> \
#defects</div><div><br></div><div>There is no need to change anything. The message \
#failures correctly combines #unexpectedFailures and #unexpectedPasses. The message \
#defects combines #errors and #failures.</div><div><br></div><div>The use of the \
instance variables failures, errors, and passes is an implementation detail that can \
stay is it is for this use case.</div><div><br></div><div>@Chris: Why did it matter \
that those instance variables refer to tests the current \
way?</div><div><br></div><div>Best,</div><div>Marcel</div><div \
class="mb_sig"></div><blockquote class="history_container" type="cite" \
style="border-left-style:solid;border-width:1px; margin-top:20px; \
margin-left:0px;padding-left:10px;"> <p style="color: #AAAAAA; margin-top: 10px;">Am \
30.05.2019 01:25:14 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div \
style="font-family:Arial,Helvetica,sans-serif">On Wed, May 29, 2019 at 04:07:11PM \
-0500, Chris Muller wrote:<br>> > > Would you mind helping me out with one \
then?<br>> ><br>> > What are the challenges exactly you are trying to tackle here? \
Can you provide more context?<br>> <br>> I had to think about this -- I think,<br>> \
abstractly, the case comes up when something that "should" (or "should<br>> not") \
work, is in conflict with whether we want it or expect it to<br>> work. We can look \
as close as the trunk image for a good example.<br>> <br>> \
SocketTest>>#testSocketReuse<br>> <br>> This test is expected to fail on Windows. \
For sake of argument, let's<br>> pretend that the reason is because there is a \
security hole in Windows<br>> (surely not! ;) ) and so we, as developers of Squeak, \
commented out<br>> windows support in the VM because we *absolutely positively want \
this<br>> to fail on Windows* until we're sure the coast is clear.<br><br>This is a \
test for platform-specific functions that are known to be<br>unavailable when running \
on a Windows VM. We expect it to fail when<br>running on Windows. \
SocketTest>>expectedFailures makes this explicit.<br><br>If Squeak is running on a \
Windows VM, this test will fail, and the<br>failure is expected. It is an expected \
failure.<br><br>That seems reasonable to me.<br><br>If it is not clear what an \
"expected failure" is, then a good method<br>comment in TestCase>>expectedFailures \
might help. And if we cannot<br>agree on the method comment, then it's a sure bet \
that we should not<br>be fiddling with the \
implementation.<br><br>Dave<br><br><br></div></blockquote> </div></body>
[Attachment #6 (text/plain)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic