All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Naumann <dev@andin.de>
To: buildroot@busybox.net
Subject: [Buildroot] Buildroot runtime test infrastructure prototype
Date: Tue, 30 Jun 2015 22:26:28 +0200	[thread overview]
Message-ID: <5592FB74.3010608@andin.de> (raw)
In-Reply-To: <1581556904.2327180.1435653528950.JavaMail.root@openwide.fr>

Hi Thomas, Jeremy,

here is my first shot:
https://bitbucket.org/anaum/br_robot

For now I have implemented building a config and running the ext2/3/4 
filesystem checks. Didnt get around doing the qemu part yet, but it 
should be enough to get the idea. Just follow the README.
Install the RIDE editor if you can, even though it crashes sometimes it 
makes the structure very clear and provides additional debug output 
while executing the tests.

Also I have not invested in test documentation, but look at the 
report/log.html and see if that's suitable. Comments on other 
interesting features below...


>> syntax you have to learn, while Python is known by a large number of
>> people already.
True to some extend, and I must admit that the variable syntax takes a 
little getting used to.
But besides that the API documentation for the libraries is very good 
and what's more, if you use RIDE editor to write the testcases (which I 
do almost exclusively), you hardly have to worry about the syntax. It 
works a bit Excel-like, suggests keywords and shows their documentation 
in a tooltip when pressing CTRL). Helps in navigation from testcases to 
keyword implementation, does global rename...


> pretty good, RFW can report in an xunit-compatible xml which can be
> easily parsed by whatever tool you prefer. I have been autogenerating
> reports with it for quite some time

I'd be interested, how is that different from the report.html that you 
mention below? What tools are you using?

> RFW also generates some HTML pages ready to be pushed on a server,
> but that's less usefull for the buildroot use-case.

On feature that I really like is the html linkage of the test report to 
the log, so often it's possible to find the problematic spot without 
digging through ascii-logfiles. Have a look at that and maybe make a 
testcase fail.
>
>> Can it run tests in parallel?
>
> no, RFW core has no parallel testing capabilities by itself. There
> are plugins to do that, though...

Well I havnt looked at any parallel plugin, but you can start the pybot 
execution as often as you like. It's just a matter of defining different 
tests for different runs. I think the tagging feature helps a lot with 
that. E.g. each package specific tests would be tagged with their 
package name and then you would have a run for each tag starting with 
a*, b*, ... so about 26 threads running side by side.
Another solution could be running each suite separatly.

There's a tool called rebot which can be used to combine the results 
(output.xml) of the different runs.

And there's an option in pybot to run just tests that either failed or 
have not been executed in a previous run (using the previous output.xml).

>> Can we
>> easily integrate the tests with Jenkins to have them run everyday?

The jenkins plugin works great, we use it in combination with jenkins 
matrix jobs to get the parallelization. At the moment we run about 10 
different targets in our testbed, but they mostly do the same tests with 
different configuration data. Anyway there's a job at the end that 
accumulates all the results into one report.

And finally we are interested in getting more coverage in that report as 
well as we would be able to provide results from real HW instead of qemu 
only. So of course I'd be happy to see a way of integrating buildroots 
test with our system...


regards,
Andreas

  parent reply	other threads:[~2015-06-30 20:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-25 18:02 [Buildroot] Buildroot runtime test infrastructure prototype Thomas Petazzoni
2015-06-26 15:48 ` Andreas Naumann
2015-06-26 16:20   ` Jeremy Rosen
2015-06-28  9:50     ` Thomas Petazzoni
2015-06-30  7:06       ` Andreas Naumann
2015-06-30  7:39         ` Thomas Petazzoni
2015-06-30  8:38           ` Jeremy Rosen
2015-06-30  8:46             ` Thomas Petazzoni
2015-06-30 20:26             ` Andreas Naumann [this message]
2015-07-01  8:53               ` Jeremy Rosen
2015-06-30 16:06       ` Jeremy Rosen
2015-07-01  7:30         ` Andreas Naumann
2015-07-01  7:57           ` Jeremy Rosen
2015-07-01 10:28           ` Denis Thulin
2015-07-02 13:57             ` Andreas Naumann
2015-06-26 18:12 ` Thomas De Schampheleire
2015-06-26 18:26   ` Thomas De Schampheleire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5592FB74.3010608@andin.de \
    --to=dev@andin.de \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.