Say I'm writing a compiler that targets QBE IL. How should I test its output, since the fields of a Module are private ?

One way is to pretty-print it and rely on string comparison : this is, it seems, how the QBE backend of antimony is tested. However, this method makes the tests depend on serialization, which is somewhat brittle : for instance, antimony tests have to perform some kind of normalization on string representations before comparing them.

Another way is to test the module's content (functions, type definitions, data definitions) before it is wrapped into a module, since these structs have public fields and can therefore be directly inspected and tested. This can work if you are willing to leave the top-level structure (that is, the module) untested.

So, dealing with these private fields is possible, if inconvenient, but are they really needed in the first place ? I don't really get the rationale behind making them private.

Note that I gave the example of compiler testing here but the same concern would apply for anything that needs to consume QBE instead of generating it : analyses or optimizations on the IL, or alternative compiler backend (QBE -> assembly).