summaryrefslogtreecommitdiff
path: root/tests/README
diff options
context:
space:
mode:
Diffstat (limited to 'tests/README')
-rw-r--r--tests/README8
1 files changed, 4 insertions, 4 deletions
diff --git a/tests/README b/tests/README
index 406ea8e..a6f9605 100644
--- a/tests/README
+++ b/tests/README
@@ -1,7 +1,7 @@
-TL;DR: run test_calendar-cli.sh, don't run tests.sh.
+TL;DR: do run test_calendar-cli.sh, don't run tests.sh - unless you know what you're doing.
-Probably we should add some standard python test code here that can be run through nose or tox, but after all this is a command line utility - hence I found it appropriate to start with functional tests written to be executed from through a shell.
+test_calendar-cli.sh will attempt to set up a radicale server and a xandikos server, and run tests.sh towards those two. At least one of those should be installed for the tests to work. It will bind up some hard coded ports on localhost, tests will fail if those ports are already in use. (Oups - xandikos doesn't work very well together with calendar-cli at the moment, so it has been skipped).
-The file tests.sh will run towards whatever calendar server is configured in .config/calendar.conf, and it has potential side effects, it will wipe out any prior events within the time range 2010-10-10 and 2010-10-14.
+The actual tests are in tests.sh. You'll have to run this one if you want to check compatibility with other calendar servers, but it requires either that the $calendar_cli environmental variable is set, or that some calendar server is configured in .config/calendar.conf. If you choose to run the tests towards some old, existing calendar, then be aware that the test code may eventually delete some historic data from 2010.
-The file test_calendar-cli.sh will set up a radicale calendar server, run the tests.sh towards radicale, then set up xandikos and run tests.sh towards xandikos.
+Probably we should add some standard python test code here that can be run through nose or tox, but after all this is a command line utility - hence I found it appropriate to start with functional tests written to be executed from through a shell.