The Trunk: CollectionsTests-jar.349.mcz

> 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"!

> 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"!
>