The current code is an absolute mess, difficult to get the head wrapped around it, and difficult to understand how the calendar(s) and objects are cleaned up or not. THe logic should be simplified.
Some thoughts:
- There is an old "compatibility flag" unique_calendar_ids - do we need it still? We should look through those cases where it's needed, try to understand why it's needed and make checks for it in the caldav-server-checker script.
- Some calendar servers does not support creating new calendars - and I did have an idea once-upon-a-time to allow the test to be able to access a "production calendar" and do stuff there without disturbing the test runs. Hence the need to be able to wipe "things known to have been made by the tests" from the test calendar. However, it's extremely bloat to run this logic after each and every test. Perhaps have local list of UIDs used per test and remove those before/after the test run?
calendar.delete() now has a workaround, on servers not supporting calendar deleting all objects will be deleted. It should probably be followed up with a flag to the calendar create method allowing it to create calendars without raising errors if the calendar already exiss. So that it's possible to run create and delete transparently on calendars not supporting it. At least given that the test calendar already exists.
The current code is an absolute mess, difficult to get the head wrapped around it, and difficult to understand how the calendar(s) and objects are cleaned up or not. THe logic should be simplified.
Some thoughts:
calendar.delete()now has a workaround, on servers not supporting calendar deleting all objects will be deleted. It should probably be followed up with a flag to the calendar create method allowing it to create calendars without raising errors if the calendar already exiss. So that it's possible to run create and delete transparently on calendars not supporting it. At least given that the test calendar already exists.