413 / 478
deploys the code to staging, and then reruns the FTs against that—automating one more
step of the process, and ensuring that your staging server is automatically kept up to
date with the latest code.
Some people even use a CI server as the way of deploying their production releases!
Tips on CI and Selenium Best Practices
Set up CI as soon as possible for your project
As soon as your functional tests take more than a few seconds to run, you’ll find
yourself avoiding running them all. Give this job to a CI server, to make sure that
all your tests are getting run somewhere.
Set up screenshots and HTML dumps for failures
Debugging test failures is easier if you can see what the page looked at when the
failure occurs. This is particularly useful for debugging CI failures, but it’s also very
useful for tests that you run locally.
Use waits in Selenium tests
Selenium’s
implicitly_wait
only applies to uses of its
find_element
functions,
and even that can be unreliable (it can find an element that’s still on the old page).
Build a
wait_for
helper function, and alternate between actions on the site, and
then some sort of wait to see that they’ve taken effect.
Look in to hooking up CI and staging
Tests that use
LiveServerTestCase
are all very well for dev boxes, but the true
reassurance comes from running your tests against a real server. Look into getting
your CI server to deploy to your staging server, and run the functional tests against
that instead. It has the side benefit of testing your automated deploy scripts.
More Things to Do with a CI Server
|
385