Skip to content

A
avocado

openeuler / avocado

通知 0
Star 0
Fork 0
A
avocado

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 22 2月, 2018 11 次提交
  3. 17 2月, 2018 13 次提交
  5. 16 2月, 2018 9 次提交
    • L
      tap: Make warnings more visible · 83add27a
      由 Lukáš Doktor 提交于 
      TAP does not defines WARN(ing) test status, but allows comments. Let's
simply note the test finished with some warnings which is better than
nothing.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>
      83add27a
    • L
      tap: Report "CANCEL" test status as "SKIP" · 876d3b07
      由 Lukáš Doktor 提交于 
      TAP does not defines nor knows about "CANCEL" test status, it only
defines "SKIP" and "TODO". Let's map the "CANCEL" test status to "SKIP"
to comply with the specification.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>
      876d3b07
    • C
      text_mux.py: adapt to how Python 3 records type names · 02c3b6e4
      由 Cleber Rosa 提交于 
      Which adds the namespace of the function that created the class.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      02c3b6e4
    • C
      test_mux.py: avoid comparing None with integers · ea0b31b9
      由 Cleber Rosa 提交于 
      Which is OK under Python 2, but not under Python 3.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      ea0b31b9
    • C
      xunit plugin: do not print bytes on stdout · 5e27ebdb
      由 Cleber Rosa 提交于 
      When the xunit plugin is writing to the stdout, we don't want a
representation of bytes, but the bytes encoded as a string users can
read.

We're sticking to the 'UTF-8' encoding here because it's already
hard coded here in the document (as opposed to the encoding the
user may have set to its stdout).

Before this patch, `avocado run /bin/false --xunit -` results in:

b'<?xml version="1.0" encoding="UTF-8"?>\n<testsuite errors="0" failures="0" name="avocado" skipped="0" tests="1" time="0.018056154251098633" timestamp="2018-02-13 12:34:55.627077">\n\t<testcase classname="SimpleTest" name="1-/bin/true" time="0.018056154251098633"/>\n</testsuite>\n'

After this patch it becomes:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite errors="0" failures="0" name="avocado" skipped="0" tests="1" time="0.018121719360351562" timestamp="2018-02-13 12:34:15.669379">
        <testcase classname="SimpleTest" name="1-/bin/true" time="0.018121719360351562"/>
</testsuite>
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      5e27ebdb
    • C
      xunit plugin: fix DOM usage · bfab1c6b
      由 Cleber Rosa 提交于 
      On Python 3, it's not possible to create Elements detached from a
Document.  The following code fails (later than it should) on Python
3:

   >>> from xml.dom.minidom import Element
   >>> e = Element('foo')
   >>> e.setAttribute('bar', 'baz')
   Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/lib64/python3.6/xml/dom/minidom.py", line 741, in setAttribute
      attr.ownerDocument = self.ownerDocument
   AttributeError: ownerDocument

Let's create elements within the document, with the `createElement`
API.  According to the docs "The element is not inserted into the
document when it is created", so the (unchanged) code that actually puts
the element in the right place still applies.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      bfab1c6b
    • C
      avocado.utils.iso9660: always deal with bytes · 01c84866
      由 Cleber Rosa 提交于 
      The avocado.utils.process module has been changed so that the content
of stdout and stderr are now bytes.  The content generated by the
iso9660 backend implementations should also operate on bytes, given
that it makes little sense for the library to assume a given content
type of a file (inside an iso9660 archive).

To make the data returned by the various backend `read()`
implementations always return bytes on both Python 2 and 3, an
explicit conversion is done from strings to bytes (which affects only
Python 2, since Python 3 already operates with bytes on files opened
in binary mode).
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      01c84866
    • C
      avocado.utils.process: use bytes for raw stdout/stderr · 7d0e6a44
      由 Cleber Rosa 提交于 
      This brings a change in behaviour, in which the stdout/stderr of the
executed process will now be of bytes type, instead of a string type.

Two new attributes, which are implemented as properties, have been
added to the CmdResult class, `stdout_text` and `stderr_text`.  Those
are convenience methods that will return the same content that is in
`stdout` and `stderr`, reespectively, but decoded on the fly[1].

With regards to encoding, if one is not provided, the result of
`sys.getdefaultencoding()` will be used ("utf-8" for Python 3 and
"ascii" for Python 2).

Applications and/or tests using the APIs that return a CmdResult
should, to the best of my knowledge, set a default encoding themselves
so a stable behavior across Python versions.  But that if left to
users of this API.

A different tradeoff/design decision has to do with the tests modified
here.  One option is to have "text" (as in sequences of human readable
glyphs) as being of Python type "str".  On Python 2, "str" can be
compared to "bytes" because a conversion will happen on demand.  That
is, the following is fine on Python 2:

   >>> result = process.run("command")
   >>> "expected" in process.stdout

Where `expected` is of type "str" and `process.stdout` is of type
"bytes".  This is not true of Python 3, so either the types must match
or a conversion must be done explicitly.  The solutions to that are:

1) have these "text" as (of type) "bytes" in the source code itself,
   and avoid the conversion whenever possible
2) have "strings" in the source code itself, and use the conversion
   provided by `CmdResult.stdout_text` and `CmdResult.stderr_text`.

The approach chosen here is to avoid conversion if possible, that is,
use "byte" types, given the fact that the source code encoding is by
default 'ascii' and most of the "text" dealt with here can be
represented in 'ascii' too.  This is equivalent of doing:

   result = process.run("command")
   b"expected" in process.stdout
   "errors: %s" % 0 in process.stderr_text

[1] The obvious alternative, instead of decoding these on the fly
    would be to have multiple copies of the "same" data.  This assumes
    that binary data produced on the stdout/stderr will usually be
    larger than textual data.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      7d0e6a44
    • C
      Merge remote-tracking branch 'ldoktor/result-dispatchers' · 15d436d7
      由 Cleber Rosa 提交于 
      Signed-off-by: NCleber Rosa <crosa@redhat.com>
      15d436d7
  7. 15 2月, 2018 7 次提交