[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
|