1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
//! Read-only CalDAV/CardDAV tests against Google.
//!
//! Google speaks CalDAV/CardDAV over HTTPS but only behind an OAuth2
//! Bearer token (no app passwords), and it rejects collection creation
//! (`MKCALENDAR`/`MKCOL`), so these tests only cover the read-only
//! subset: discovery plus listing.
//!
//! Mint an access token out of band (the OAuth2 dance is the caller's
//! job; this crate only forwards the token as `Authorization: Bearer`),
//! then run with:
//!
//! ```sh
//! GOOGLE_ACCESS_TOKEN="ya29...." \
//! cargo test --test google -- --ignored
//! ```
//!
//! These tests are intentionally not wired into CI: Google access
//! tokens expire after about an hour, so a stored secret would be stale
//! by the time CI runs. Running them unattended would mean a
//! refresh-token exchange step on every push; they are kept manual.
//!
//! Note on Google's non-standard discovery: only the `.well-known`
//! entry behaves oddly. `.well-known/carddav` 301-redirects, but only
//! for an *authenticated PROPFIND* (a plain GET 404s), so the CardDAV
//! test starts at that entry via [`common::google_carddav_base`].
//! `.well-known/caldav` does not redirect at all, so the CalDAV test
//! targets the resolved API host directly.
use env;
/// Discovery + calendar listing against Google Calendar.
/// Discovery (via the authenticated `.well-known/carddav` redirect) +
/// addressbook listing against Google Contacts.