Some window gravities require a division by two. Up to now,
test-gravity.c expected this division to always be rounded up. This
commit changes the code to also allow rounding down.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of messing with CMake's environment and having that implicitly
inherited when running a process, explicitly set $SOURCE_DIRECTORY where
required.
Signed-off-by: Uli Schlachter <psychon@znc.in>
tests/run.sh uses awesome-client to actually make awesome run the test.
If awesome-client fails, then the only error message that is printed look like:
== Running /home/travis/build/awesomeWM/awesome/tests/test-leaks.lua ==
Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
E: dbus-send failed.
make[4]: *** [CMakeFiles/check-integration] Error 1
To also get the output from awesome, this commit makes failures from
awesome-client non-fatal so that the following shell code can notice the
failure and hopefully print some useful information.
Signed-off-by: Uli Schlachter <psychon@znc.in>
STRICT_TESTS was introduced in commit c22b93963. Some people have setups
where e.g. fontconfig produces warnings. These warnings made the tests
under tests/examples/ fail. The above commit changes things so that
these warnings are ignored by default, unless STRICT_TESTS is enabled.
Commit b5ca8bf937 broke this by making example test failures fatal
again.
Fix this by appending "|| true" to the command to run in case strict
tests are disabled. Thus, all failures from tests/examples/runner.sh get
ignored.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of running the example tests directly from CMake and checking
the results via CMake, the tests are now run through a shell script.
So far, there are too many variables involved for me to easily figure
out how to run this shell script in the building phase instead of the
configuring phase, but at least this commit moves the "actual running"
out of CMake, bringing us a step closer to that goal.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a .txt file next to each example test that generates a
text output. This text file contains the expected output and it is an
error if the actual output does not match the expected output. This
means that we no longer have to run the example tests before we can
expand all the @foo@ expressions that occur.
While touching this, I also fixed some typos and unexpected newlines in
the tests' output.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since last year luacheck change, trailing spaces are no longer
allowed. This caused all documentaiton examples that used them
as a way to mark newlines to look plain wrong.
This commit add an explicit flag to make longer examples more
readable.
* Add a FOLLOW_SYMLINKS so Awesome 3rd party module can share the
awesome test infrastructure by adding themselves as symlinks in
`lib/`, `tests/` and `tests/examples` and otherwise use AwesomeWM
Travis config.
* Add an option to add examples to the C documentation. Previously only
Lua functions could be documented using this framework.
This allows to figure out if a test will generate an image without
having to run it. The long term plan for this is to run the tests during
compiling ("make") and not during configuring ("cmake"). Since the list
of files to e.g. install needs to be known during configuring, this
commit is a necessary step in that direction.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No currently existing test produces a PNG image, so why do we even check
for such an output file?
I did 'rm -rf build && make -j9 && cp -r build /tmp', then applied this
patch, and then did another 'rm -rf build && make -j9'. According to
diff, the resulting directories are basically the same (except for lots
of timestamps and some non-determinism in CMake).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows to e.g. easily run awesome from source (for an hour) via
TEST_TIMEOUT=42d tests/run.sh /dev/null.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is not really a test. It just starts xeyes and sees if anything
explodes.
However, the reason for this test is to stabilise code coverage.
Apparently, Gtk(?) sometimes creates shaped windows. This had the effect
that codecov always reports random changes to code coverage, depending
on if this specific test run saw any shaped client windows or not.
Thus, by explicitly adding a test that runs a shaped client, hopefully
these random fluctuations disappear.
Hopefully-fixes: https://github.com/awesomeWM/awesome/issues/1975
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Emmanuel Lepage Vallee
mergify[bot]
Uli Schlachter
Yauhen Kirylau
Rastislav Barlik