O atributo "InternalsVisibleTo" é essencial para qualquer tipo de teste de "caixa branca" (o termo da década, eu acho) para o .Net. Ele pode ser colocado em qualquer arquivo c # com o atributo "assembly" na frente. Observe que os DOCs da Microsoft dizem que o nome do assembly deve ser qualificado pelo token de chave pública, se estiver assinado. Às vezes isso não funciona e é preciso usar a chave pública completa no local. O acesso a componentes internos é essencial para testar sistemas concorrentes e em muitas outras situações. Consulte https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054 . Neste livro, Meszaros descreve uma variedade de estilos de codificação que basicamente constituem uma abordagem "Design For Test" para o desenvolvimento de programas. Pelo menos é assim que eu tenho usado ao longo dos anos.
ADICIONADO: Desculpe, não estou aqui há um tempo. Uma abordagem é chamada de "subclasse de teste" por Meszaros. Novamente, é preciso usar "internalsvisableto" para acessar os internos da classe base. Essa é uma ótima solução, mas não funciona para classes seladas. Quando ensino o "Design For Test", sugiro que seja uma das coisas que devem ser "pré-projetadas" nas classes base para fornecer testabilidade. Tem que se tornar quase uma coisa cultural. Crie uma classe base "base" que não esteja lacrada. Chame-o de UnsealedBaseClass ou algo uniformemente reconhecível. Esta é a classe a ser subclassificada para teste. Também é subclassificado para construir a classe de produção selada, que geralmente difere apenas nos construtores que expõe. Eu trabalho na indústria nuclear e os requisitos de teste são levados muito a sério. Então, eu tenho que pensar sobre essas coisas o tempo todo. A propósito, deixar ganchos de teste no código de produção não é considerado um problema em nosso campo, desde que sejam "internos" em uma implementação .Net. As ramificações de NÃO testar algo podem ser bastante profundas.