Commit a944636c02 "bashified" tests/run.sh for some reason.
Afterwards, commit 4abd820051 fixed some of the fall-out.
However, there is still a problem left.
We have "set -e" in this script. Thus, whenever some command exits with
status 0, the script abort. When the variable errors is zero/unset, the
command "((errors++))" has exit status zero. Thus, this instruction
caused the shell script to abort. This was not intended.
Fix this by using "((++errors))" instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, the test runner used a timer which fired every 0.1 seconds
to "do its thing". Many of these waits seem unnecessary.
This commit makes the test runner wait 0 seconds for the first call of a
step function. Only following calls will have a timeout of 0.1 seconds
applied.
A full run of the test suite (tests/run.sh without further arguments)
took about 100 seconds before this change. After this change, we are
down to 60 seconds. This is almost factor two faster! (Well, five thirds
is the exact number, so factor 1.66)
(The numbers are best out of three runs. The "before" number is rounded
down while the "after" number is rounded up.)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously we got the following unhelpful error message:
tests/_client.lua:98: bad argument #2 to 'assert' (string expected, got
userdata)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Copy-paste-y I was checking for the wrong result. Another unrelated
problem with the test runner caused me to miss this. Sorry!
Signed-off-by: Uli Schlachter <psychon@znc.in>
This removes a duplicate test and moves some "spawn with empty string as
argument" up to the long list of similar tests (and adds error
checking).
I do not see the point of the assert(#client.get() == 0) and so it was
just dropped.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 5e6a893 broke error handling in awesome.spawn(): Instead of
returning an error message, it would just return its last argument.
This commit fixes that, removes some not-so-helpful warnings, and adds
lots of tests for this code.
Fixes: https://github.com/awesomeWM/awesome/issues/1281
Signed-off-by: Uli Schlachter <psychon@znc.in>
Locally I got this, where only two xterms were opened.
```
% tests/run.sh test-awesomerc.lua
awesome_log: /tmp/tmp.ToAKs6Gw4J/_awesome_test.log
== Running test-awesomerc.lua ==
Error: timeout waiting for signal in step 1/11 (@20).
===> ERROR running test-awesomerc.lua! <===
Error: timeout waiting for signal in step 1/11 (@20).
There were 1 errors!
```
This is a partial revert of commit 7901a1c647. The end result is the
same, but the change from that commit is reverted and instead the same
thing is done in a different way.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Ever since these files were added, these problems existed. I have no
idea what alt_fg is supposed to mean, but since a value of nil is
apparently ok, I just pass in nil directly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I really try to avoid doing this, psychon too, but enough is
enough. We don't have a solution and I would rather add more
tests that work than keeping a test that keep "failing" just
to remind us it's there.
Previously, the API to set the data that should be displayed was
:set_data(t) where t is a table. This table has the labels to use as its
keys and the numbers as its values. With this API, it was not possible
to influence the order in which the "pie pieces" were drawn.
This commit adds and uses a new API called :set_data_list(t). Here, t is
a table with integer keys and tables as values, thus one can iterate
over this with ipairs() and the order is well-defined. The tables used
as values contain the label as their first entry and the number as their
second entry.
Fixes: https://github.com/awesomeWM/awesome/issues/1249
Signed-off-by: Uli Schlachter <psychon@znc.in>
This test has a list of "things" that should be present in the output. This
table is iterated over via pairs(), which means that the output is
non-deterministic and the order of the entries is basically random.
Fix this by using ipairs() to get a deterministic iteration order. This requires
some slight change to the table that is iterated over.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This printed a table. This will make Lua print the address of the table and
hence the output of this test was non-deterministic.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There we go again... When hitting a slow CI node, there is again
timeouts when doing the multi-screen tests. As no solution to
bug leading to this has been found, the only thing to do is
increase the timeout.
Hopefully this commit will be reverted soon.
Spawn callbacks were never invoked when no startup-notification-rules were
given. This commit fixes the code so that "startup done" callbacks are also
called when no rules were given.
Fixes: https://github.com/awesomeWM/awesome/issues/1218
Signed-off-by: Uli Schlachter <psychon@znc.in>
Via this, I can set HEADLESS=1 in my wrapper-GNUMakefile that I use and
"make check" will no longer open a new window that gets in my way.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in luaA_client_swap() is incorrect, because
luaA_object_emit_signal() already pops the arguments to the signal.
Still, the code here tried to remove the arguments from the Lua stack
again, thereby corrupting the stack (removing more items than there are
in the stack).
Normally, popping more things from the stack than it has entries
silently corrupts the Lua stack. Apparently this doesn't necessarily
cause any immediate issues, because this code has been broken since nine
months and no one noticed. This mistakes was introduced in commit
55190646.
This issue was only noticed by accident. Thus, this commit also adds a
small integration test that exercises this bug. This test catches the
issue, but only on Travis, because there we are building our own version
of Lua 5.3 and that one has assertions enabled.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The usual "a or b"-trick to simulate C's ?:-operator does not work when
"false" is a valid value. Fix the code to handle this correctly and add
a short unit test which would have caught this problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>