[squeak-dev] Two tests failing in trunk but not 5.1

David T. Lewis lewis at mail.msen.com
Mon Apr 30 20:23:58 UTC 2018


On Fri, Apr 27, 2018 at 10:36:17PM -0500, Tim Johnson wrote:
> Hi,
> 
> I ran some tests and found a couple that are failing.  I also checked 
> and found these tests don't fail in my 5.1 image.
> 
> BrowserTest>>#testBuildMessageCategoryBrowserEditString
> DebuggerExtensionsTest>>#testCollectionsGeneralise
> 
> I think the first one might actually be a case where a bug was fixed.  
> The test fails because of a timeout, because there is a dialog on-screen 
> which is not returning.  Not sure, but the test may be intended to 
> declare that the dialog should appear, and now it is (?).
> 
> The second one, I don't understand.  There is no comment.

I don't understand it either, and strangely it has no method timestamp.
But the test was was introduced in April 2013 in this update:

  Name: ToolsTests-fbs.62
  Author: fbs
  Time: 19 April 2013, 8:43:40.116 am
  UUID: 926d563e-d57b-44ec-b4e7-672010293c2b
  Ancestors: ToolsTests-nice.61
  
  Tests for the new #canonicalArgumentName Debugger methods.

This is part of test coverage for #canonicalArgumentName, which is implemented
in Object and also has no method timestamp or comment (!!!).

The canonicalArgumentName method is sent by many unit tests, so it has very
good coverage (even though I don't know the significance of this failing test).

Aside from unit tests, it is sent by Message>>createStubMethod and appears
to be used when the debugger provides a template for implementing a missing
method, or for implementing a method override.

The test does this:

  testCollectionsGeneralise
      self assert: Collection name equals: Array new canonicalArgumentName.
      self assert: Collection name equals: OrderedCollection new canonicalArgumentName.
      self assert: Collection name equals: LinkedList new canonicalArgumentName


This looks like a regression that should be fixed such that the tests pass
again, and that also deserves a good method comment in Object>>cononicalArgumentName.

I think that some more background and explanation can probably be found on
squeak-dev circa April 2013, notably this reference:

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170506.html

Which points to this:

  Name: Tools-fbs.460
  Author: fbs
  Time: 19 April 2013, 8:40:24.143 am
  UUID: d5cf82c4-bda7-48ff-bfbd-e8b27d0a07d7
  Ancestors: Tools-fbs.459
  
  When creating a stub method, give the argument names that represent the
  (usual) desired name more accurately. For instance, Arrays, OrderedCollections
  and Sets all result in 'aCollection', ByteStrings and WideStrings in 'aString',
  and so on.

So perhaps that last paragraph about "when creating a stub method..." might serve
as a method comment for Object>>cononicalArgumentName?

Dave

> 
> Image/VM info:
> 
> Squeak6.0alpha
> latest update: #17922
> Image format 6521 (32 bit)
> 
> Virtual Machine
> ---------------
> C:\Users\tcj\Desktop\squeak.cog.spur_win32x86_201803080952\Squeak.exe
> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives 
> VMMaker.oscog-eem.2347]
> Win32 built on Mar  8 2018 11:08:39 GMT Compiler: 6.4.0
> platform sources revision VM: 201803080952
> 
> Cheers,
> Tim
> 


More information about the Squeak-dev mailing list