Testing Drupal core with siteeffect

Timm Jansen — Sun, 16 Aug 2015 17:21:38 +0000

Drupal has been one of siteeffect’s major use case since the beginning as I used to run a lot of Drupal sites which were under constant development. I have been working with Drupal for more then 9 years and grew into the very active community over time. Working on Drupal core at some of the camps it quickly became clear that Drupal 8 core was a perfect use case. Very active development, frequent major changes, a fast moving HEAD. I first presented siteeffect at the Dev Days in Szeged in 2014 and got feedback from the leading frontend core devs on how siteeffect could actually help to test D8 core. I started to automate everything that was needed to easily test a patch from the issue queue.

Following are a couple of issues containing regressions that got uncovered by siteeffect until then:

We are now able to trigger the test of a patch over a single command and certain members of the community will be notified by mail when all tests are done. Triggering tests manually will soon be automated as well. The hardest part in this whole process has been to figure out how results can be fed back into the issue queue. As you can see from browsing the above issues we tried gifs / side by side pngs / inline in issues / dropbox… This was especially discussed at the last Dev Days 2015 in Montpellier at a BOF after my presentation on the progress of siteeffect and D8 core. As a result it is now possible to download gifs and preview pngs directly form the frontend, which can then be posted to the issue queue.

One major problem has been that a default installation is missing – for example – nodes or comments. Therfore the node and comment edit forms couldn’t be tested as they simply don’t exist. A solution to this might be possible now with migrations paths being required for all updates. We could use one installation as a base with manually added nodes, comments & config and then spin of testing installations from this. Work in progress…

Something that came out of this process and that is useful for all Drupal sites (7 and 8) is a custom siteeffect Drupal module that tracks every url back to its menu router item. Why is that useful? In core it doesn’t make sense to test 1000+ menu edit forms, five should suffice. The same is the case for a client Drupal site. It might take a long time to test thousands of single news entries. To get a good idea of what’s going on you want to test 25 samples out of news, events, blog posts and user profiles. siteeffect closely interacts with the module. If new urls are being added to the project then siteeffect will ask the module to resolve the urls to its menu router items and then checks if a certain amount of these types of urls already exists in your project. This only has to be done once and can even be run against a dev server, no need to install the module on the live site.

Der Beitrag Testing Drupal core with siteeffect erschien zuerst auf siteeffect.

private beta

Timm Jansen — Tue, 14 Apr 2015 22:42:42 +0000

The last month showed that siteeffect is ready for more beta testers so we will be pulling in the next batch of users soon. If you are interested in testing siteeffect, sign up.

Der Beitrag private beta erschien zuerst auf siteeffect.