Skip to content

A
avocado

openeuler / avocado

通知 0
Star 0
Fork 0
A
avocado

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

切换分支/标签
  1. 28 3月, 2018 2 次提交
  3. 22 3月, 2018 2 次提交
  5. 20 3月, 2018 1 次提交
    • C
      Travis-CI: whitelist style check errors · aadb1c9a
      由 Cleber Rosa 提交于 
      The latest jobs have been failing because of the following issues:

    ************* Module raise
    E1130: 48,30: Raise.test: bad operand type for unary -: NoneType
    ************* Module selftests.functional.test_basic
    I1101:1191,24: PluginsXunitTest.run_and_check: Module 'lxml.etree'
    has not 'XMLSchema' member, but source is unavailable. Consider
    adding this module to extension-pkg-whitelist if you want to
    perform analysis based on run-time introspection of living
    objects.
    I1101:1191,40: PluginsXunitTest.run_and_check: Module 'lxml.etree'
    has not 'parse' member, but source is unavailable. Consider adding
    this module to extension-pkg-whitelist if you want to perform
    analysis based on run-time introspection of living objects.
    I1101:1193,43: PluginsXunitTest.run_and_check: Module 'lxml.etree'
    has not 'parse' member, but source is unavailable. Consider adding
    this module to extension-pkg-whitelist if you want to perform
    analysis based on run-time introspection of living objects.
    ************* Module selftests.unit.test_xunit
    I1101: 91,24: xUnitSucceedTest.test_add_success: Module
    'lxml.etree' has not 'XMLSchema' member, but source is
    unavailable. Consider adding this module to
    extension-pkg-whitelist if you want to perform analysis based on
    run-time introspection of living objects.
    I1101: 91,40: xUnitSucceedTest.test_add_success: Module
    'lxml.etree' has not 'parse' member, but source is
    unavailable. Consider adding this module to
    extension-pkg-whitelist if you want to perform analysis based on
    run-time introspection of living objects.
    I1101: 92,43: xUnitSucceedTest.test_add_success: Module
    'lxml.etree' has not 'parse' member, but source is
    unavailable. Consider adding this module to
    extension-pkg-whitelist if you want to perform analysis based on
    run-time introspection of living objects.

We can't whitelist the `lxml.etree` module at this time (inspekt doesn't
have such an option) and the raise failure is a false positive.  Let's
ignore those issues then.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      aadb1c9a
  7. 15 3月, 2018 1 次提交
    • C
      Python 3: load JSON as supported on 3.4 (and earlier) · d2b4edc3
      由 Cleber Rosa 提交于 
      Under Python 3.4, which runs on our CI and is our lowest supported
version, json.loads() requires a string, while newer versions also
allows bytes.

    >>> json.loads(b'{}')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/home/cleber/.local/lib/python3.4/json/__init__.py", line 312, in loads s.__class__.__name__))
    TypeError: the JSON object must be str, not 'bytes'

Let's make that code compatible with Python 3.4.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      d2b4edc3
  9. 13 3月, 2018 1 次提交
  11. 08 3月, 2018 1 次提交
  13. 23 2月, 2018 7 次提交
  15. 22 2月, 2018 5 次提交
  17. 16 2月, 2018 1 次提交
    • 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
  19. 15 2月, 2018 3 次提交
  21. 13 2月, 2018 3 次提交
  23. 12 2月, 2018 2 次提交
  25. 10 2月, 2018 1 次提交
    • A
      SIMPLE tests: improve status API · c42bfbc9
      由 Amador Pahim 提交于 
      Currently simple tests have a limited status API, being able to set only
the WARN status by generating an output string in a very specific and
hard-coded format.

This patch, while respects the current behaviour, creates configuration
keys, allowing users to provide regular expressions to search for in the
test outputs, aiming to set the final test status to either WARN or SKIP
when the test finishes with exit code 0.
Signed-off-by: NAmador Pahim <apahim@redhat.com>
      c42bfbc9
  27. 08 2月, 2018 1 次提交
    • C
      Test statuses: do not rely on varianter_yaml_to_mux plugin · 6e14beb9
      由 Cleber Rosa 提交于 
      Which is an optional plugin, and the test statuses feature is at the
innermost core of Avocado.  While the original test indeed saved a lot
of duplicated code, it's code that serves a specific testing purpose,
and it's better to be simpler and more verbose and with the right (no)
dependencies.

This issue came up during the Python 3 port work.  Now that all the
unittests (selftests/unit/*) were passing (locally, there's one other
PR pending to be accepted), the next logical step is getting the
"core" functional (selftests/functional/*) tests passing.  Because
the 'varianter_yaml_to_mux' optional plugins port is not done, the
"core" functional tests fail and the current work flow is broken.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      6e14beb9
  29. 21 12月, 2017 1 次提交
  31. 16 12月, 2017 1 次提交
  33. 14 12月, 2017 1 次提交
  35. 12 12月, 2017 1 次提交
    • C
      avocado.core.sysinfo: use avocado.utils.process · 224f7187
      由 Cleber Rosa 提交于 
      The sysinfo code replicates some of the process handling code
already in avocado.utils.process.  Let's use our library instead
and remove code duplication.

This also marks the sysinfo interruption tests as "time and resource
sensitive", and will not run on environments such as Travis-CI, in
a similar way that other interruption based tests are currently set.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      224f7187
  37. 06 12月, 2017 1 次提交
  39. 30 11月, 2017 4 次提交
    • C
      Output check: add a test for API call check mode enforcement · 11f3b0df
      由 Cleber Rosa 提交于 
      The avocado.utils.process APIs offer the `allow_output_check`
parameter which exists at a function call level, and thus should be
applied only during the scope of that function.

While it's questionable if a test process should be able to skip
some of its generated output (by means of an `avocado.utils.process`
function parameter), the fact is that the utility libraries offer
that at a lower level.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      11f3b0df
    • C
      Output check: allow for an explicit `none` mode · 9997aaa1
      由 Cleber Rosa 提交于 
      In commit 4514a8ad, the default value from the command line option
`--output-check-record` was being used to set the mode of the
`avocado.utils.process` APIs with regards to output record mode.

The problem with that is it makes it impossible for the API to
distinguish between "no explicit behavior requested" and "explicitly
being asked to disable recording".
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      9997aaa1
    • C
      Output check: also support checking against 'output.expected' · f0f9a3fe
      由 Cleber Rosa 提交于 
      Avocado recently introduced the support to record the combined
output generated by a test.  Now, this introduces support for
checking against a previously record combined output.

If an 'output.expected' file exists, it'll take precedence
over the `stdout.expected` and `stderr.expected` files.

Also it's necessary to switch the default operation mode for
the `avocado.utils.process` functions, since to compare with
an `output.expected` file, the record mode for the currently
running test has to be the same.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      f0f9a3fe
    • C
      Output check: remove test that is already run in compound scenarios · 0f95b571
      由 Cleber Rosa 提交于 
      The same code is run on multiple other tests.  It's a waste to run
it yet another time by itself.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
      0f95b571