blog.liw.fi → posts → 2026 → Riki internal linking tests

Goal

I had code and test for internal linking. I rewrote the code to be in a Site type, but lost the tests, as they were hard to add. Now I don't know if my code works. Actually, I know there's problem.

The goal for today is to add tests for internal linking, following the specification in doc/linking.md.

Plan

  • I have helper functions to produce candidate pages for resolving a link on a page. Add unit tests for these. Each function is easy to test in isolation.
  • Add unit tests for the Site::resolve method to test the order in which candidate target pages are tried.

Notes

  • To make it easier to set up a Site for testing, add a Site::fake_page method, only usable for tests. Also add a testing-only Site::empty constructor.
  • Sibling test, easy.
  • Direct subpage, tricky. Apparently the code I have is broken. It's the code I rewrote from what I thought was working code, but I'm not convinced that actually worked either. This is why tests are important.
  • A tricky bit: the origin page is, for example, /src/foo.mdwn, which means its internal name is /foo. There is also the target page /src/foo/bar.mdwn, with internal name /foo/bar. A link bar on the origin page should resolve to the target page. I can join bar (the link) with the origin internal name (/foo) to get /foo/bar. That's not a full page name, though. It lacks the fully qualified path the source file: I can get the source directory from the Site, but not the suffix (.mdwn).
  • Maybe the internal name of the target would be enough? I can have Site::resolve do a lookup with that. The hash map of pages uses internal names for lookup, anyway.
  • Now that I think about it, the helper functions that construct possible targets for links should return a PathBuf representing the internal name, not a full PageName. The full names are trickier to construct in all cases. Ideally it'd be a dedicated type, but I'll start with the generic PathBuf.
  • Actually, an optional PathBuf - sometimes it's not possible to construct the candidate
  • I'll throw away all the code and start over.
  • I do, however, want to have my own type for the set of pages, instead of a raw HashMap, since I have to change everywhere it's used. Future me will thank me and so will present me.
  • That was a lot of furious rewriting and refactoring, but it works now.
  • Merged.