I keep coming across simple bugs in untested APIs, and sometimes I try to write simple unit tests for those APIs. To make this easier, I have started to create a "svn_test__sandbox" class, with which a C test can very easily set up a repository and a working copy, like the Python tests do. Then it can run the low-level functions that it is unit-testing.
[[[ test_read_write_tree_conflicts(const svn_test_opts_t *opts, apr_pool_t *pool) { svn_test__sandbox_t sbox; ... SVN_ERR(svn_test__sandbox_create(&sbox, "read_write_tree_conflicts", opts, pool)); SVN_ERR(svn_wc__db_op_set_tree_conflict(sbox.wc_ctx->db, child_abspath, conflict, pool)); ... } ]]] That may not be the purist way to perform unit testing, but it is very practical. Many of the libsvn_wc tests are already using it. I intend that it should have a set of utility functions like the Python test suite's "sbox.simple_update()" etc. An example of this is implemented in subversion/tests/libsvn_wc/op-depth-test.c, and used like this: { svn_test__sandbox_t b; SVN_ERR(svn_test__sandbox_create(&b, "del_replace_not_present", opts, pool)); SVN_ERR(wc_mkdir(&b, "A")); SVN_ERR(wc_mkdir(&b, "A/B")); SVN_ERR(wc_mkdir(&b, "A/B/X")); SVN_ERR(wc_mkdir(&b, "A/B/Y")); SVN_ERR(wc_mkdir(&b, "A/B/Z")); SVN_ERR(wc_commit(&b, "")); ... } We can move it outside of tests/libsvn_wc to be available to the other library tests as soon as we think it's useful enough. I'm open to any feedback. - Julian