On 04/06/2017 02:20 PM, Eduardo Habkost wrote:
> On Thu, Apr 06, 2017 at 12:38:31PM -0400, Cleber Rosa wrote:
> [...]
> Do you have any suggestions for making the test result output
> from those scripts easily consumable by the Avocado test runner?
>
If those tests are treat
On Thu, Apr 06, 2017 at 12:38:31PM -0400, Cleber Rosa wrote:
[...]
> >>> Do you have any suggestions for making the test result output
> >>> from those scripts easily consumable by the Avocado test runner?
> >>>
> >>
> >> If those tests are treated as SIMPLE tests, then all of their output
> >> wil
On 04/06/2017 11:00 AM, Lukáš Doktor wrote:
> Dne 5.4.2017 v 17:06 Cleber Rosa napsal(a):
>>
>> On 04/05/2017 09:00 AM, Eduardo Habkost wrote:
>>>
>>> Hi,
>>>
>>> I have been writing a few standalone Python scripts[1] to test
>>> QEMU recently, and I would like to make them more useful for
>>> pe
Dne 5.4.2017 v 17:06 Cleber Rosa napsal(a):
On 04/05/2017 09:00 AM, Eduardo Habkost wrote:
Hi,
I have been writing a few standalone Python scripts[1] to test
QEMU recently, and I would like to make them more useful for
people running tests using Avocado.
Most of them work this way:
1) Query
On 04/05/2017 09:00 AM, Eduardo Habkost wrote:
>
> Hi,
>
> I have been writing a few standalone Python scripts[1] to test
> QEMU recently, and I would like to make them more useful for
> people running tests using Avocado.
>
> Most of them work this way:
> 1) Query QEMU to check which
>arch
Some quick thoughts about what you could do (points 1 and 2, other
paragraphs are more thoughts on making avocado better for such cases):
1) For the cases using unittest, you could try to import avocado, if it
fails, fall back to unittest.TestCase, such as
try:
from avocado import Test as Tes
Hi,
I have been writing a few standalone Python scripts[1] to test
QEMU recently, and I would like to make them more useful for
people running tests using Avocado.
Most of them work this way:
1) Query QEMU to check which
architectures/machine-types/CPU-models/devices/options
it supports
2)
