| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
When running avocado tests in a sequence on the same host, further tests
are affected by cleaner default_mapping built from obfuscating specific
keywords also. Prevent adding these keywords to the mapping.
Resolves: #3165
Signed-off-by: Pavel Moravec <pmoravec@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, mocked files were kept under the `tests/test_data/`
directory and generally mimic'd the file location they would be
temporarily copied to during the execution of their relevant tests.
This has a few maintainability drawbacks, and the handling of the
`files` attribute for test cases as either strings or tuples is at best
confusing.
Improve on this by instead making the `files` references relative to
where the test case file is written. This enables easier maintenance by
keeping all test requirements closer together, rather than spread across
the repo. As such, the `files` attribute now requires a list of tuples,
taking the form `(relative_src, absolute_dest)`. Additionally, fake
plugins for tests that need them to artificially test a specific
criteria should also be included in the test's subdir now.
Along with this change, move several StageTwo tests to their own subdirs
that now contain both the test cases and the needed files for mocking.
This should be the new design pattern going forward - if a test needs to
mock files of any kind, put it in a new subdirectory (and if it doesn't
need to mock files, continue to keep it in the relevant directory within
the test suite).
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was discovered that setting a specific plugin timeout via the `-k
$plugin.timeout` option could influence the timeout setting for other
plugins that are not also having their timeout explicitly set. Fix this
by moving the default plugin opts into `Plugin.__init__()` so that each
plugin is ensured a private copy of these default plugin options.
Additionally, add more timeout data to plugin manifest entries to allow
for better tracking of this setting.
Adds a test case for this scenario.
Closes: #2744
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a `report` or `collect` run would use `--clean` or `--mask` to do
in-line obfuscation of collected reports, sos would not read the config
section for clean - it would only be read if `sos clean` was called
directly. As such, users would need to manually specify config file
values for each run.
Alleviate this gap by reading the config section for `clean` if either
of the cleaner options are used. Do this before we apply cmdline options
so that we maintain our order of precedence.
Related: RHBZ#1950350
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avocado will, by default, use the "recursive" behavior when looking
for tests. It means that the class hierarchy will be crawled
recursively, until, for "avocado-instrumented" tests, the top-most
parent "avocado.Test" is found.
When the "enable" behavior is activated, it forces the class to be
considered one containing avocado-instrumented tests, but, it disables
the recursive behavior and only the tests local to that specific class
are found.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
A supplement of #1399 fix, now also for adding strings or special
device files.
Also adding a (vendor) test case for it.
Resolves: #2560
Signed-off-by: Pavel Moravec <pmoravec@redhat.com>
|
|
|
This commit represents the start of an overhaul of the test suite used
by sos. Note that several more commits to follow will be required in
order for the test suite to be considered stable.
The new test suite will use the avocado-framework to build out new
tests.
This first part adopts a new 'stageX' naming scheme for our tests as
follows:
stage0 -> Unittests
stage1 -> Basic function tests, no mocking allowed
stage2 -> Mocked tests for specific scenarios/regressions
stage3 -> Complex setups for layered products/environments
At the moment, these unittests are not updated for avocado, though most
should still work with `nosetest` directly.
A new set of base classes is defined in tests/sos_tests.py which provide
the foundation for actual tests cases. This approach entails new test
cases subclassing a base class, such as the new `StageOneReportTest`,
and setting the `sos_cmd` class attr to the _options_ for an sos report
run. By default `sos report --batch` will be run, and targeted to the
test job's directory as a tmpdir.
Each sos command will be executed once, and all test_* methods within a
test case that subclasses `StageOneReportTest` will be checked against
the output of that execution. Note that this diverges from avocado's
typical approach where each test_* method is performed against a brand
new instance of the class (thus meaning any setup including our sos
report run would normally be run fresh). However, after speaking with
the avocado devel team, this is still seen as a valid pattern for the
framework.
The current organizational approach is to separate the tests by
component rather than stage. For example. `tests/report_tests/` should
hold any report-centric tests, and the `plugin_tests` directory therein
should be used for plugin-specific tests. As of this commit, there are
basic functionality tests under `tests/report_tests/` and a single
plugin test under `tests/report_tests/plugin_tests/` to act as a POC.
Further, there is a `tests/vendor_tests/` directory for organizing
vendor-specific bug/feature tests that are not covered by the generic
project-wide tests. A POC test from RHBZ1928628 is available with this
commit.
Note that in order for these tests to be run properly _without_
installing the current branch to the local system, you will need to run
the following command:
`PYTHONPATH=tests/ avocado run -t stageone tests/`
Related: #2431
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
