The Trunk: CollectionsTests-jar.349.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: CollectionsTests-jar.349.mcz

commits-2
David T. Lewis uploaded a new version of CollectionsTests to project The Trunk:
http://source.squeak.org/trunk/CollectionsTests-jar.349.mcz

==================== Summary ====================

Name: CollectionsTests-jar.349
Author: jar
Time: 8 February 2021, 8:25:19.407373 pm
UUID: f484ba2b-2035-b046-9222-c3e4e42a7ad4
Ancestors: CollectionsTests-ul.348

Test to show differing SharedQueue and SharedQueue2 semantics

=============== Diff against CollectionsTests-ul.348 ===============

Item was added:
+ ----- Method: AbstractSharedQueueTest>>testContention2 (in category 'tests') -----
+ testContention2
+ "and here's a test case that distunguishes SharedQueue from SharedQueue2 semantics:
+ SharedQueue2 produces a sequence #(5 10 15) while SharedQueue produces #(5 15 10)"
+
+ | q r1 r2 r3 |
+ q := self queueClass new.
+
+ [ r1 := q next. q nextPut: 15. r3 := q next ] fork.
+ [ r2 := q next ] fork.
+
+ Processor  yield.   "let the above two threads block"
+
+ q nextPut: 5.
+ Processor yield.    "let the first thread above proceed"
+
+ q nextPut: 10.
+ Processor yield.    "let the unfinished thread above finish"
+
+ q class = SharedQueue2 ifTrue: [
+ self assert: 5 equals: r1.
+ self assert: 10 equals: r2.
+ self assert: 15 equals: r3.
+ self assert: nil equals: q nextOrNil ].
+
+ q class = SharedQueue ifTrue: [
+ self assert: 5 equals: r1.
+ self assert: 15 equals: r2.
+ self assert: 10 equals: r3.
+ self assert: nil equals: q nextOrNil ].
+
+ "SharedQueue2 implementation using a Monitor checks the queue for available data while
+ the SharedQueue implementation based on a Semaphore checks for excessSignals > 0,
+ which results in these two different outcomes"!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: CollectionsTests-jar.349.mcz

Levente Uzonyi
Hi David,

While these tests pass now and document something about shared queues, I
don't think we should have them in the Trunk.
I prefer the design-by-contract approach for tests where there are
actual requirements to be satisfied by the subject of the tests to make
them pass.
These tests do not describe such requirements, so if the implementations
change, they'll start failing, which some may interpret wrongly as actual
errors.
Another problem with them is that people may feel like they can relying on
the behavior described by these tests since there are tests for them.


Levente

On Sat, 13 Feb 2021, [hidden email] wrote:

> David T. Lewis uploaded a new version of CollectionsTests to project The Trunk:
> http://source.squeak.org/trunk/CollectionsTests-jar.349.mcz
>
> ==================== Summary ====================
>
> Name: CollectionsTests-jar.349
> Author: jar
> Time: 8 February 2021, 8:25:19.407373 pm
> UUID: f484ba2b-2035-b046-9222-c3e4e42a7ad4
> Ancestors: CollectionsTests-ul.348
>
> Test to show differing SharedQueue and SharedQueue2 semantics
>
> =============== Diff against CollectionsTests-ul.348 ===============
>
> Item was added:
> + ----- Method: AbstractSharedQueueTest>>testContention2 (in category 'tests') -----
> + testContention2
> + "and here's a test case that distunguishes SharedQueue from SharedQueue2 semantics:
> + SharedQueue2 produces a sequence #(5 10 15) while SharedQueue produces #(5 15 10)"
> +
> + | q r1 r2 r3 |
> + q := self queueClass new.
> +
> + [ r1 := q next. q nextPut: 15. r3 := q next ] fork.
> + [ r2 := q next ] fork.
> +
> + Processor  yield.   "let the above two threads block"
> +
> + q nextPut: 5.
> + Processor yield.    "let the first thread above proceed"
> +
> + q nextPut: 10.
> + Processor yield.    "let the unfinished thread above finish"
> +
> + q class = SharedQueue2 ifTrue: [
> + self assert: 5 equals: r1.
> + self assert: 10 equals: r2.
> + self assert: 15 equals: r3.
> + self assert: nil equals: q nextOrNil ].
> +
> + q class = SharedQueue ifTrue: [
> + self assert: 5 equals: r1.
> + self assert: 15 equals: r2.
> + self assert: 10 equals: r3.
> + self assert: nil equals: q nextOrNil ].
> +
> + "SharedQueue2 implementation using a Monitor checks the queue for available data while
> + the SharedQueue implementation based on a Semaphore checks for excessSignals > 0,
> + which results in these two different outcomes"!

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: CollectionsTests-jar.349.mcz

David T. Lewis
Hi Levente,

You are right. I removed the test from trunk.

The AbstractSharedQueueTest>>testContention2 test in CollectionsTests-jar.349
is a useful description of the current behavior, so may want to refer
to that if the differences cause problems.

Sorry for the noise.

Dave

On Sat, Feb 13, 2021 at 10:12:39PM +0100, Levente Uzonyi wrote:

> Hi David,
>
> While these tests pass now and document something about shared queues, I
> don't think we should have them in the Trunk.
> I prefer the design-by-contract approach for tests where there are
> actual requirements to be satisfied by the subject of the tests to make
> them pass.
> These tests do not describe such requirements, so if the implementations
> change, they'll start failing, which some may interpret wrongly as actual
> errors.
> Another problem with them is that people may feel like they can relying on
> the behavior described by these tests since there are tests for them.
>
>
> Levente
>
> On Sat, 13 Feb 2021, [hidden email] wrote:
>
> >David T. Lewis uploaded a new version of CollectionsTests to project The
> >Trunk:
> >http://source.squeak.org/trunk/CollectionsTests-jar.349.mcz
> >
> >==================== Summary ====================
> >
> >Name: CollectionsTests-jar.349
> >Author: jar
> >Time: 8 February 2021, 8:25:19.407373 pm
> >UUID: f484ba2b-2035-b046-9222-c3e4e42a7ad4
> >Ancestors: CollectionsTests-ul.348
> >
> >Test to show differing SharedQueue and SharedQueue2 semantics
> >
> >=============== Diff against CollectionsTests-ul.348 ===============
> >
> >Item was added:
> >+ ----- Method: AbstractSharedQueueTest>>testContention2 (in category
> >'tests') -----
> >+ testContention2
> >+ "and here's a test case that distunguishes SharedQueue from
> >SharedQueue2 semantics:
> >+ SharedQueue2 produces a sequence #(5 10 15) while SharedQueue
> >produces #(5 15 10)"
> >+
> >+ | q r1 r2 r3 |
> >+ q := self queueClass new.
> >+
> >+ [ r1 := q next. q nextPut: 15. r3 := q next ] fork.
> >+ [ r2 := q next ] fork.
> >+
> >+ Processor  yield.   "let the above two threads block"
> >+
> >+ q nextPut: 5.
> >+ Processor yield.    "let the first thread above proceed"
> >+
> >+ q nextPut: 10.
> >+ Processor yield.    "let the unfinished thread above finish"
> >+
> >+ q class = SharedQueue2 ifTrue: [
> >+ self assert: 5 equals: r1.
> >+ self assert: 10 equals: r2.
> >+ self assert: 15 equals: r3.
> >+ self assert: nil equals: q nextOrNil ].
> >+
> >+ q class = SharedQueue ifTrue: [
> >+ self assert: 5 equals: r1.
> >+ self assert: 15 equals: r2.
> >+ self assert: 10 equals: r3.
> >+ self assert: nil equals: q nextOrNil ].
> >+
> >+ "SharedQueue2 implementation using a Monitor checks the queue for
> >available data while + the SharedQueue implementation based on a Semaphore
> >checks for excessSignals > 0, + which results in these two different
> >outcomes"!
>