If you don’t have some kind of acceptance tests, you should probably add some. Personnally I like to use Capybara with PhantomJS/Poltergeist and this post takes this stack as example, but other testing options will most likely have similar behavior.
Let’s see what’s going on in a simple scenario:
- Go to Page A
- Click button “Reveal the hidden Form X”
- Input data in Form X
- Submit Form X
- Expect that it creates an item in the database
Let’s say that step 2 triggers a CSS animation. If the animation is not done by the time step 3 runs, it can fail because Form X is not visible yet (by default Capybara doesn’t find hidden elements). This is particularly annoying since the failure will be random, depending on the speed of the machine running the specs.
You could solve the problem by doing this:
… or wait until the element is visible …
… but that’s not great as it requires you to either change or slow down your tests.
I’d recommend disabling CSS animations entirely in your test environment. To do so, you can include this into your code:
Firstly, do not disable animations if you consider them to be very important and you want to test them. Pretty obvious I think.
There might also be some weirder cases where the fix above won’t work. For instance if the animation’s end frame is the one holding the visibility state, not running the animation will break the reveal. Here is an example courtesy of Benjamin showcasing this situation:
In this case waiting for the animation to be done seems like the way to go. You could also change your logic to a simpler way of doing CSS3 animations.
For The Same Price: Faster Tests
Interesting fact, by removing CSS animations we sped up by a couple of percents our test suite.