On Wed, 2020-12-09 at 09:55 -0500, Brian J. Murrell wrote:
>
> Can we have discussions messages e-mailed to us, or is this more like
> a
> "Forum" type of interaction where one has to just keep checking back
> at
> the website periodically in case t
On Wed, 2020-12-09 at 10:43 -0500, Cleber Rosa wrote:
>
> Hi Brian,
Hi Cleber,
> We enabled GitHub "Discussions" in an experimental way (the feature
> itself
> is also a preview),
Indeed. We got invited on our project to enable it.
> The short answer is that, we were using GitHub "Issues"
On Wed, 2020-12-09 at 11:37 -0300, Willian Rampazzo wrote:
> Hello, Avocado community,
Hello Willian
> We have enabled Discussions on Avocado Framework GitHub Project. Feel
> free
> to ask questions, add suggestions, or comment on an open discussion!
How does that relate to this list? Are they
If I call self.fail() in a test_* method, the test reports FAIL as I
would expect.
If I call self.fail() from setUp() (or presumably tearDown()) the test
reports ERROR.
Is this intended behaviour? Am I not able to have a test report FAIL
from setUp() or tearDown()?
Cheers,
b.
signature.asc
On Fri, 2019-05-10 at 08:10 +0200, Lukáš Doktor wrote:
>
> I'm not sure whether I understand properly, what are you trying to
> achieve. From time to time I need to find particular result that
> executed certain tests. I do that simply by:
>
> ls *DATE*/test-results/*test_name*
But what if
On Thu, 2019-05-09 at 12:11 -0400, Cleber Rosa wrote:
>
> Let me know how that sounds... it should be a few lines of Python
Yes, that sounds like an interesting solution.
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
Hi.
Having to sift through dozens of directories of the format:
job-results/job--MM-DDTHH.MM-
trying to find the results for a given test is frustrating.
While I realize that I can get the name of the dir to look into from
the avocado stdout, that stdout is not where I am looking when I
Are the tags given to a --filter-by-tags argument available in the test
(i.e. setUp(), test_* functions, etc.)?
The idea of course is so that a test can know which tags were requested
possibly for skipping, etc.
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
On Tue, 2019-01-08 at 14:57 +0100, Vit Pelcak wrote:
> Hello.
Hi,
While not really answering your question, per se but perhaps you are
trying to solve the wrong problem...
>
> That will mean extra 10 minutes for each of them as
> VM
> will have to be started each time, resulting in extra 30
Any opinions on the preference of initializing Test class attributes in
setUp() vs. the more traditional __init__()?
I.e. if my tearDown() is:
def tearDown(self):
print self.foo
self.foo needs to be initialized. Typically in python objects, this is
done in __init__(), but given that
On Mon, 2018-11-26 at 17:03 +0100, Lukáš Doktor wrote:
>
> This is a new information. So are you actually looking for job--
> MM-DDTHH.MM-UID only, or are you looking for test-name => test-
> output-dir mapping?
I'm looking to correlate a given display of one of mnay xunit test
results in
So, at the end of a test run of a thousand or so tests I have all of
this xunit output and all of these jobs-results directories.
I can't seem to find any way to correlate one with the other. There is
no indication (that I have found) in the xunit file of those names that
are in the numerous
Any thoughts on supporting unittest's expectedFailure() decorator?
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
On Thu, 2018-11-15 at 10:17 -0500, Brian J. Murrell wrote:
> If I have a test class with a setUp(), test*() function(s) and a
> tearDown(), is it true that if some operation in a test*() function
> causes a segfault, tearDown() won't get run?
This certainly seems to be the case. A q
If I have a test class with a setUp(), test*() function(s) and a
tearDown(), is it true that if some operation in a test*() function
causes a segfault, tearDown() won't get run?
If this is true, what is the advise for writing/structuring tests that
are testing, say, a library (through python
On Tue, 2018-11-13 at 12:49 -0500, Cleber Rosa wrote:
>
> AFAICT, every test gets this handler installed.
...
> I don't see a code path in which test processes don't have the
> sigterm
> handler installed, but there are different code paths regarding the
> ending of the test process. On the
When I run a sample test:
```
import time
from avocado import Test
class TimeoutTest(Test):
timeout = 3
def setUp(self):
print "setUp"
def tearDown(self):
print "tearDown"
def test(self):
try:
sleep_time = self.params.get('sleep_time',
On Fri, 2018-11-09 at 18:35 +0100, Lukáš Doktor wrote:
> The fastest way would be to send a PR to
> master.
I will see if I can carve time for that.
> Slightly slower could be to raise an issue on github,
https://github.com/avocado-framework/avocado/issues/2908
Cheers,
b.
On Fri, 2018-11-09 at 08:46 +0100, Lukáš Doktor wrote:
>
> * In normal execution:
> * Test receive status after test PID finished = 10
> * Test PID died after test status delivered = 60
I'm not sure what those two are trying to describe exactly.
> * In interrupted execution
If I set a timeout for a test, that seems to include the tearDown()
also, so that effectively any test that times out doesn't get to run
it's tearDown().
Is my understanding correct? If so, is there any way around this?
Even timed out tests can need post-test processing. A timed-out test
which
Hi.
Is there some kind of time limit on the setUp() method? 60 seconds
perhaps?
If so, what if my per-test setup takes longer than 60 seconds?
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
On Tue, 2018-11-06 at 20:16 +0100, Lukáš Doktor wrote:
>
> Yes, this is related to the fact that the code is not being executed,
> but only analyzed on discovery.
The only difference between the two test_example.py files though is
what it adds via sys.path.append():
-sys.path.append('./')
On Tue, 2018-11-06 at 17:20 +0100, Lukáš Doktor wrote:
>
> The ":avocado: recursive" is used for test discovery. The main
> difference is that for test discovery we don't load the modules.
> Instead we use static analysis (using `ast`) to detect whether
> certain file is python and contains
On Tue, 2018-11-06 at 16:38 +0100, Lukáš Doktor wrote:
>
> Here you have to call setUp of the parent class by:
A. I thought avocado was doing some kind of magical introspection
or some such to take care of that detail.
> otherwise python simply returns without looking at parent(s). Note
>
On Tue, 2018-11-06 at 08:39 +0100, Lukáš Doktor wrote:
>
Hi Lukáš.
> it looks like you had to make more changes to get this working
> without deploying your classes, anyway it should work (and we use it
> heavily).
Still can't seem to get it to work.
> The simplest way to give this a try
Can I subclass avocado as described at
https://avocado-framework.readthedocs.io/en/latest/SubclassingAvocado.html
with 52.1?
I tried duplicating[1] the structure described there exactly and
running the test_example.py passes but I don't see any of the
self.log.info() messages in the job.log.
If I run an external test tool with process.system(), say, and that
test tool produces it's own junit output, is there any way to have
avocado consume that and make it available in it's own job-
results/*/results.xml file rather than just the simplified "pass/fail"
result that it puts in there for
27 matches
Mail list logo
