summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/automated_builds_and_tests
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/src/blueprint/automated_builds_and_tests')
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/Debian_packages.mdwn6
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/build.mdwn6
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/continuous_integration.mdwn32
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/cucumber.mdwn3
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests/testing.mdwn67
5 files changed, 112 insertions, 2 deletions
diff --git a/wiki/src/blueprint/automated_builds_and_tests/Debian_packages.mdwn b/wiki/src/blueprint/automated_builds_and_tests/Debian_packages.mdwn
new file mode 100644
index 0000000..88b45eb
--- /dev/null
+++ b/wiki/src/blueprint/automated_builds_and_tests/Debian_packages.mdwn
@@ -0,0 +1,6 @@
+- <http://jenkins-debian-glue.org/>
+- [debile](http://anonscm.debian.org/gitweb/?p=pkg-debile/debile.git)
+- [Jenkins configuration for Kamailio Debian
+ Packaging](https://github.com/sipwise/kamailio-deb-jenkins):
+ glueing Jenkins, pbuilder, reprepro, jjb, nginx,
+ jenkins-debian-glue, piuparts, DEP-8, and more together.
diff --git a/wiki/src/blueprint/automated_builds_and_tests/build.mdwn b/wiki/src/blueprint/automated_builds_and_tests/build.mdwn
new file mode 100644
index 0000000..7a1ac82
--- /dev/null
+++ b/wiki/src/blueprint/automated_builds_and_tests/build.mdwn
@@ -0,0 +1,6 @@
+# Tools
+
+## live-autobuild
+
+<http://live.debian.net/gitweb/?p=live-autobuild.git> is currently
+used to build "official" daily Debian Live images
diff --git a/wiki/src/blueprint/automated_builds_and_tests/continuous_integration.mdwn b/wiki/src/blueprint/automated_builds_and_tests/continuous_integration.mdwn
new file mode 100644
index 0000000..a68b068
--- /dev/null
+++ b/wiki/src/blueprint/automated_builds_and_tests/continuous_integration.mdwn
@@ -0,0 +1,32 @@
+This page is about continuous integration servers.
+
+[[!toc levels=2]]
+
+# Tools
+
+## buildbot
+
+We [[used to have a buildbot setup|todo/automated_builds_and_tests/buildbot]].
+
+buildbot ([homepage](http://buildbot.net)) is a continous integration
+bot, able to communicate over mail or IRC. Used by many projects.
+
+Buildbot can be seen as a [framework](http://jacobian.org/writing/buildbot/) to
+deploy continuous integration. It has no real configuration file, but
+what deserves this role is a file that can be thought programatically.
+Thus it provide a very flexible environment that can be customize for
+most projects needs.
+
+Some interesting pages, might be worth reading for people willing to
+play with buildbot and understand its logic :
+
+* [Chromium's buildbot config](http://src.chromium.org/viewvc/chrome/trunk/tools/build),
+ which is the one driving their [builbot instance](http://build.chromium.org/)
+* [Buildbot's documentation](http://buildbot.net/buildbot/docs/latest/)
+* Tor project's [buildbot
+ configuration](https://gitweb.torproject.org/admin/buildbot-conf.git)
+
+## Jenkins
+
+We currently use Jenkins. See [[our dedicated page|automated builds
+and tests/jenkins]] for our notes about it.
diff --git a/wiki/src/blueprint/automated_builds_and_tests/cucumber.mdwn b/wiki/src/blueprint/automated_builds_and_tests/cucumber.mdwn
index efa8a31..ca7790b 100644
--- a/wiki/src/blueprint/automated_builds_and_tests/cucumber.mdwn
+++ b/wiki/src/blueprint/automated_builds_and_tests/cucumber.mdwn
@@ -1,4 +1,3 @@
[[!meta title="Automated tests using cucumber"]]
-Merged for 0.17.2, see [[todo/automated_builds_and_tests]] for
-pointers to design and usage documentation.
+Merged in 0.17.2, see [[test/automated_tests]].
diff --git a/wiki/src/blueprint/automated_builds_and_tests/testing.mdwn b/wiki/src/blueprint/automated_builds_and_tests/testing.mdwn
new file mode 100644
index 0000000..908c533
--- /dev/null
+++ b/wiki/src/blueprint/automated_builds_and_tests/testing.mdwn
@@ -0,0 +1,67 @@
+[[!meta title="Automated testing tools"]]
+
+We already have [[an automated test suite|contribute/release_process/test/automated_tests]].
+This page is about tools that could allow us to improve it.
+
+[[!toc levels=2]]
+
+# Tools
+
+## behave
+
+* [homepage](https://github.com/behave/behave)
+* Cucumber-like, in Python
+* used by GNOME
+* examples from the eog source tree, that use *behave* and *dogtail*:
+ - [feature](https://git.gnome.org/browse/eog/tree/tests/actions.feature)
+ - [steps definition](https://git.gnome.org/browse/eog/tree/tests/steps/steps.py)
+* not in Debian (2014/08/05)
+* Python (with Jython) is now Sikuli's preferred scripting language;
+ it's also the language that has the best maintained bindings to
+ interact with libvirt, accessibility technologies, and more
+* does *behave* work fine under Jython?
+
+## dogtail
+
+* [homepage](https://fedorahosted.org/dogtail/)
+* GUI test tool and automation framework written in ​Python
+* uses Accessibility (a11y) technologies to communicate with
+ desktop applications
+* used by GNOME in combination with *behave*: see the section about
+ that one
+* in Debian Wheezy
+* how much do we still need Sikuli if we have dogtail?
+
+## LDTP
+
+LDTP is an open source testing tool that uses computer assistive
+technology (accessibility) to automate GUIs. It's used by GNOME,
+Mozilla and others:
+
+* [[!wikipedia Linux_Desktop_Testing_Project]]
+* [homepage](http://ldtp.freedesktop.org/wiki/)
+* [tutorial](http://download.freedesktop.org/ldtp/doc/ldtp-tutorial.pdf)
+* The main bindings are Python, but there also are a Ruby client and
+ Perl bindings in the [Git repo](http://cgit.freedesktop.org/ldtp/ldtp2/tree/ldtp)
+* The LDTP dev mailing-list is very quiet, and it's unclear whether
+ GNOME still uses it, or instead switched to dogtail.
+
+## misc
+
+- Martin Pitt
+ [announces](http://www.piware.de/2013/02/umockdev-record-and-mock-hardware-for-debugging-and-testing/)
+ umockdev ([source code](https://github.com/martinpitt/umockdev)),
+ a set of tools to record and mock hardware for debugging and testing
+
+# Open questions
+
+## Using accessibility technologies?
+
+In some cases, it could simplify some testing steps, such as anything
+about navigating menus, that we're currently mostly avoiding since
+it's hard to do in a robust way with Sikuli.
+
+A downside is that we're not exactly testing how most users interact
+with the software. Some upsides are that it would ensure that our
+stuff does support accessibility technologies, and that we would have
+to maintain less pictures.