Use the advanced timestamp specification format for libfaketime.
Before using that, some tests failed on 32-bit systems due to integer
overflows. It seems like faketime translates absolute dates to relative
dates by default. Moreover, libfaketime is not able to handle relative
dates that exceed the maximum value of a signed integer. Using "-f"
skips the conversion to relative dates.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
If the faketime library is missing, show a warning and skip the test.
However, do not error out to make sure the test suite is able to
terminate successfully on systems without libfaketime.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
We always terminated run-test when reached the end of the expected
output and returned success if actual output and expected output were
the same up to this point. This resulted in run-test always returning
successfully if the actual output was a prefix of the expected output,
even if it was a proper prefix.
Check if the expected output contains more data after string comparison
has finished to ensure we only return successfully if both outputs are
actually equal.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
This adds tests for following features/scenarios:
* Recurrent appointments and events of all (repetition) types.
* Recurrent appointments with a duration of more than 24 hours.
* Overlapping recurrent appointments.
* Recurrent items and leap years.
* Recurrent items with an end date.
* Recurrent items with exceptions.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
This might turn out to be useful if we want to do performance tests and
check what happens if a day with a large amount of items is processed.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Update the value of "appearance.calendarview" used in the default
configuration file of our test suite (we now use "monthly"/"weekly"
instead of integer values). Late fix for what we broke in commit
2c5235cca70bf1c5b5e92dd5b6b178ab13b695f2.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Convert our code base to adhere to Linux kernel coding style using
Lindent, with the following exceptions:
* Use spaces, instead of tabs, for indentation.
* Use 2-character indentations (instead of 8 characters).
Rationale: We currently have too much levels of indentation. Using
8-character tabs would make huge code parts unreadable. These need to be
cleaned up before we can switch to 8 characters.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
This option wasn't converted to a proper data type when it was renamed
from "week_begins_on_monday" to "general.firstdayofweek". Convert the
boolean option into an enumeration type that can take the values
"monday" and "sunday". Also, update the documentation, add a conversion
rule to the upgrade script and convert the configuration file used in
the test suite.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Update the default configuration file used in our test suite to match
the new configuration variable naming scheme.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
We don't change any configuration nor do we modify items here, so we can
safely invoke calcurse in read-only mode. Fixes a couple of permission
errors seen with `make distcheck`.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
We really don't want to use the calcurse(1) binary from "$PATH" here.
Introduce an environment variable "$CALCURSE" which can be used specify
the binary to use and set this variable to the binary located in the
build directory by default. Similarly, add another environment variable
"$DATA_DIR" that can be used to specify a data directory.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Add tests and the dummy data directory to "EXTRA_DIST" since we want
these to be shipped in distribution tarballs. Spotted with `make
distcheck`.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Now that we're fully POSIX compliant and fixed up some minor issues with
ISO C99, use "-std=c99 -pedantic -D_POSIX_C_SOURCE=200809L" as default
build flags for calcurse and the test suite.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
* search-001.sh: Compare the output of "-S <regex>" (using a regular
expression) with hardcoded data.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
* day-001.sh: Compare output of "-d<date>" with hardcoded data.
* day-002.sh: Compare output of "-d<num>" with hardcoded data.
* day-003.sh: Compare output of "-d<num>" with "-s<date> -r<num>".
* range-001.sh: Compare output of "-r" with hardcoded data.
* range-002.sh: Compare output of "-r<num>" with hardcoded data.
* range-003.sh: Compare output of "-r<num>" with "-s<date> -r<num>".
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
* todo-001.sh: Tests the "-t" command line option (calculates expected
output by parsing the todo data file).
* todo-002.sh: Tests "-t<num>" in a way similar to todo-001.sh.
* todo-003.sh: Tests "-t0" in a way similar to todo-001.sh.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
* true-001.sh: Always returns true - this should never ever fail.
* run-test-001.sh: Invokes run-test, passing itself as a parameter.
Subsequently, it outputs the very same (hardcoded) expected and actual
values.
* run-test-002.sh: Tests run-test's negative assertion feature in a way
similar to run-test-001.sh. However, output different (hardcoded)
expected and actual values and invoke run-test with the negative test
prefix ('!').
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Sometimes, we might want to make negative assertions (tests where
expected and actual output are expected/known to be different). A test
can be marked negative by prefixing it with an exclamation mark ('!'):
$ ./run-test !test-negative
Running test-negative... ok
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Introduce a new "test/" sub-directory that contains tests for calcurse.
Right now, it only includes the quick-and-dirty "run-test" helper that
can be used to run and verify tests:
$ ./run-test test-1 test-2 test-3 test-4
Running test-1... ok
Running test-2... ok
Running test-3... FAIL
Each argument passed to run-test must be a test script located in the
current directory. run-test invokes each script twice and passes the
command line argument "expected" and "actual", respectively. A test case
succeeds if both "expected" and "actual" instances return with a zero
exit status and produce exactly the same output. It fails otherwise.
run-test terminates with a non-zero exit status as soon as one of the
test fails.
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
