Shoov keeps evolving, and now has an example repo that demonstrates how we’re trying to make UI regression simpler, we took some time to implement the second feature we were missing - automatic testing on the live site.
We saw a very strange situation everywhere we looked: Dev teams were writing amazing test coverage. They were going the extra mile to setup a Travis box with environment as close as possible to the live site. They tested every single feature, and added a regression test for every bug. Heck, every commit triggered a test suite that run for an hour before being carefully reviewed and merged.
And then the site goes live - and at best they might add Pingdom monitoring to check it’s working. Pingdom at its simplest form sends an http request every minute to your site. If the answer is
200 - it means that all is good in the world. Which is of course wrong.
Our mission is to change this, and bring functional testing to the live site. One that is easy to setup and that integrates with your existing testing and GitHub flow.
While Pingdom is wonderful and is alerting us on time whenever a site goes down, its “page is fine, move along” approach doesn’t cut it for us. Here are some examples why testing on the production server is a good idea:
We are currently building a system that simplifies the task of hooking your site to a testing system. We can’t use existing systems like Travis because, as awesome as they are, they are tightly coupled with idea of being triggered by a
git commit action.
There are workarounds for that, and Circle CI does allow triggering a build from a REST api, but triggering it on the right time, notifying the right people (not just the build author), preventing overflow of emails when errors occur - all that isn’t there, or at least isn’t simple enough to setup in a single click.
There are a few principles we always try to follow, in Shoov and other projects:
The backend part is almost done, so our next task is to have a UI that helps connect GitHub repos to Shoov. We expect something similar to the interface Travis provides - a checkbox to enable or disable the service. From there it will be up to you to add a .shoov.yml file to the repo, and write some actual tests.