Build out our test suite.

[gtanner]

More of the codebase needs to be put under test.

Some thoughts as to how to get this needs to happen (demo page is nice for a smoke test but we need something automated).

Should be fine to test the final css rules applied to the element (as this is repeatable and constant) as what to test.

[ldhasson]

I have struggled with that. We definitely have methods in Core which are very amenable to better testing for sure, but how do you test that an animation is properly setup? I guess we can read back the CSS properties afterwards, but it's very minimal imho. I don't see clear benefits in testing that properties X, Y and Z have been properly altered.

[gtanner]

The key is testing what alice does, which is configure the css3 transitions on your elements. Alice doesn't do the animations, the browser does.

We don't need to test that a given css animation is rendered correctly in the browser, we need to test that when I run X on alice it generates what we would need to get the browser to render the expected animation.

[ldhasson]

So how do you do that? You expect the "Wobble" animation to set the properties x, y, and z, and so after you call it, you test that? It seems to be a "literal" test on the actual method implementation and represents no guarantee that setting x, y and z even makes sense. That's the difficulty with testing animations imho. You may want a general test on Cheshire itself and test for all the properties modified, but individual sub-effects, i am not seeing what you'd actually test at all. It's like testing a setter method that it does set the value of X to the value put in. Seems to have little value to me.

[gtanner]

A lot of stuff happens in alice that is above and beyond just setting properties x, y and z that should be under test.

• default values for arguments
• correct conversions for values like scale from and to
• warning if no elements
• adding event listeners for animationend if on Mozilla

Plugin tests can be as simple as testing that it creates the expected opts object to pass to cheshire.

The tests will be valid and shouldn't be that much of a problem. The key is we want to have coverage for everything alice does for third party contributors to have a good basis that what they are changing isn't effecting the specifications or behaviour.

I can help @mlantz write a couple of these and make the judgement call on value once we iron one or two out.

[gtanner]

Also if we want to start changing and refactoring the code it would help to have a base of tests there to make sure we don't change any behaviours.

[ldhasson]

OK, that makes sense... One thing we need to do is refactor the Core. There are key features that are being done there ,and they need to remain public for people to create additional master effects (i'll comment on the other issue). Let's make sure that those features are well defined and independent, and then composed by master effects.