[squeak-dev] Failing tests
nicolas.cellier.aka.nice at gmail.com
Mon Dec 14 11:30:37 UTC 2009
2009/12/14 Levente Uzonyi <leves at elte.hu>:
> 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
> 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.
As a general policy, I would say don't remove failing tests.
Declare them as known failures
> Building a vm with the latest VMMaker lets 6 failing test pass
> (AllocationTest, BitBltTests). It also avoids crashing linux as reported
> 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
> - 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
More information about the Squeak-dev