[squeak-dev] Writing fast tests for things that call #future:

Chris Muller asqueaker at gmail.com
Wed Jun 5 16:19:12 UTC 2013


Why was a future send introduced?  Timing issues are some of the most
maddeningly difficult to track down, especially when one _expects_ the
basic *list-widget* to WORK.  (Sorry, I feel my temperature going up
even as I type that sentence..).

I find it hard to believe that, with Morphic stepping and all the
other flexible power we have, that we require this timing-issue
compromise of using of a future send to do the progress bar...?

On Wed, Jun 5, 2013 at 6:49 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
> Now that we have a #future: send in PluggableListMorph >>
> #changeModelSelection:, we have a number of tests that fail because we
> check the state of such a list too quickly. For instance,
> MorphicToolBuilderTest >> #testSetListIndex says
>
> testSetListIndex
>     self makeList.
>     queries := IdentitySet new.
>     self changeListWidget.
>     self assert: (queries includes: #setListIndex).
>
> and the #assert: happens long before the future triggers.
>
> Now a completely stupid way of "fixing" this would be to add a Delay
> after the call to #changeListWidget. That would also smash the test
> run times, which are bad enough already.
>
> How can we write tests that run at full speed? One possible way might
> be to use a new SUnitProject whose #future:do:at:args: and
> #future:send:at:args: immediately trigger the #future: instead of
> delaying. That sound like it might bring its own problems.
>
> Other suggestions?
>
> frank
>


More information about the Squeak-dev mailing list