harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: test excludes
Date Wed, 26 May 2010 11:28:42 GMT

In message <AANLkTin2ar2LSILT2PQimKk7QtqzkTD27hVd_qjKwKJp@mail.gmail.com>,
sebb writes:
>
> On 26/05/2010, Mark Hindess <mark.hindess@googlemail.com> wrote:
> >
> > On the other hand, I'm not convinced that annotations are a good
> > solution either since they don't give you fine-grained control so
> > every distinction has to be represented by a separate method.
> 
> That seems like a positive benefit to me.

Only sometimes I think.

> If a test method has several asserts which are independent, then the
> first fail may be masking later ones.

Part of me likes the idea of splitting independent tests into separate
methods, but I can't help thinking it will be a trade off as it will
lengthen my test cycles particularly the already slow report part.

Also, consider:

    /**
     * @tests java.util.EnumMap#entrySet()
     */
    public void test_entrySet() {
        ...
        entry = (Map.Entry) iter.next();
        assertEquals("Wrong key", Size.Middle, entry.getKey()); //$NON-NLS-1$

        assertTrue("Returned false for contained object", set.contains(entry)); 
//$NON-NLS-1$
        enumSizeMap.put(Size.Middle, 3);
        assertTrue("Returned false for contained object", set.contains(entry)); 
//$NON-NLS-1$
        entry.setValue(2);
        assertTrue("Returned false for contained object", set.contains(entry)); 
//$NON-NLS-1$
        assertFalse("Returned true for uncontained object", set //$NON-NLS-1$
                .remove(new Integer(1)));

        iter.next();
        //The following test case fails on RI.
        assertEquals("Wrong key", Size.Middle, entry.getKey()); //$NON-NLS-1$
        set.clear();
        assertEquals("Wrong size", 0, set.size()); //$NON-NLS-1$
        ...
    }


I'd propose putting:

   if (Support_Excludes.isRI()) {
       ...
   }

around the asserts that fail on the RI.  You could create a new test
method but you'd end up repeating the code to build up to it so I don't
think it make sense to do that.

You are undoubtedly correct that we don't have the balance right though
(that particularly test is enormous and would be better split in to
helpful named methods distinguishing the "topics").

Regards,
 Mark.



Mime
View raw message