carddav: end-to-end test address book discovery #96
Conversation
|
I created this mostly for #87 but I think it would be useful to have something like this for all sorts of reasons. I can of course do the same thing for carddav and even one for a combined server. But as usual, I wanted to get your feedback early on, as it usually proves to be very valuable 🙂 If you think it makes sense I would also extend the test function to at least list all contacts and explicitly retrieve one (well, the only) test contact. |
carddav/carddav_test.go
Outdated
| } | ||
|
|
||
| func TestAddressBookDiscovery(t *testing.T) { | ||
|
|
carddav/carddav_test.go
Outdated
| addressBookPath: "/contacts/", | ||
| }, | ||
| { | ||
| name: "explicit-well-known", |
There was a problem hiding this comment.
Hm, I'm not sure this is an accurate test case name, the CardDAV backend has no say in what the well-known URI is. Maybe "separate-principal" would be a better name?
There was a problem hiding this comment.
Agree, but "separate-principal" is also true for the previous case. I called it nothing-at-root, as this is the distinctive feature of this case. Does that work?
As the implementation evolves, it will be necessary to have more tests to assert we don't break anything when making changes. This commit introduces a test setup to test that server and client can handle the address book discovery with various parameters. The test setup should be easily extendable to cover even more ground as needed.
bitfehler
force-pushed
the
bitfehler/carddav-tests
branch
from
bc1d6fb
to
6c2e1ae
Compare
As the implementation evolves, it will be necessary to have more tests
to assert we don't break anything when making changes. This commit
introduces a test setup to test that server and client can handle the
address book discovery with various parameters. The test setup should be
easily extendable to cover even more ground as needed.