[squeak-dev] Failing tests

Levente Uzonyi leves at elte.hu
Mon Dec 14 11:16:06 UTC 2009


Hi,

I'd like to have less failing tests in the trunk. For this, we have to 
make decisions/anwser questions.

I recently changed DecompilerTests' superclass to LongTestCase which let
us decide if we want to run these or not (when selecting all tests in Test 
Runner). By default they don't run, so they don't show up in recent 
reports (http://wiki.squeak.org/squeak/6148).
Should we change the default, so that LongTestCases are run when selected 
in the Test Runner? (Or one could add a chechbox to the gui which would 
let the user to decide if she/he wants to run long tests? Or this could be 
a preference, etc.)

Mirror primitives do not exists in the current vm. Will the vm have mirror 
primitives? Should we keep the tests? Removing these would "fix" 6 errors.

Building a vm with the latest VMMaker lets 6 failing test pass 
(AllocationTest, BitBltTests). It also avoids crashing linux as reported before
(http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/142074.html).
And it also yields slight performance improvement because of the 
primitiveNextPut fix. Why aren't vm releases available with these fixes?

There are two "great challenges" which would let most other failing tests 
pass:
- fixing traits (the issues are solved in pharo, but one has to extract 
and integrate them)
- fixing the decompiler (there's an issue with temporary variable 
declarations in inlined blocks)
Is anybody working on these?

If all the above is done, we will only have "minor" issues, like:
- TextMorphTest>>#testInitialize which tries to add itself to the 
"Scripting" flap which doesn't exists. (should we remove that part?)
- LocaleTest>>#testIsFontAvailable which probably has invalid assumptions 
about the fonts.
- MorphicToolBuilderTests>>#testGetButtonSideEffectFree


Cheers,
Levente



More information about the Squeak-dev mailing list