When I wanted to test out a change, I had print statements in the clang source code and wrote a small test file which I could use to decide whether the prints I saw matched the prints I expected to see. Revolutionary stuff, I know. One trick I like when working with huge projects is to do my printf debugging with `fprintf(stderr, ...)` instead of the project's standard logging, just to avoid having to fight with log levels and such. (These print statements should obviously be removed once they're no longer necessary; here again, using fprintf helps, because they stand out.)
I didn't even think about tests, but I'm happy to report now that the entire test suite still works after my change. I don't think any kind of test-driven debugging would have worked here; almost none of the challenge was in the actual code behind the feature, it was all mostly just work to try to understand the code base. For example, "Oh, this looks like it's where lambdas are parsed. Let me add a print here and try to compile a file with a lambda to see if I'm right", or "Ok, I think I should end up in this branch if I have a fat arrow token in a lambda expression, let's add a print statement and modify the test file to check if that's true".
I don't know about a watch mode, but I'm not sure how much that would save you as you'd constantly be relinking a very large project. It might even be counter productive. As for tooling and editors, the build system is well integrated with visual studio on Windows, and I think xcode on mac os. For linting the llvm project has clang-format and clang-tidy which are excellent tools for any C++ project. I believe there is an extensive system test suite written in Python described in the hacking docs.
Bazel makes that simple for C++ projects.