Todo método deve retornar um valor para o Teste de Unidade?

Estou aprendendo a criar testes de unidade simples para eventualmente (e espero) começar a fazer apenas TDD; por enquanto estou tentando escrever testes para códigos já escritos para ver o que pode causar problemas. Este é um deles.

Digamos que eu tenho essa classe simples (com TypeScript-> Javascript):

class PrivateStuff {
    greeting: string;
    private _thisIsPrivate;

    constructor(isPrivate: boolean) {
        this._thisIsPrivate = isPrivate;
    }

    setPrivate(option) {
        this._thisIsPrivate = option;
        console.log("_thisIsPrivate changed to : " + option);
    }

    getPrivate() {
        console.log("_thisIsPrivate is : " + this._thisIsPrivate);
        return this._thisIsPrivate;        
    }
}

E eu uso desta maneira:

let privateStuff = new PrivateStuff(false);

let buttonSet = document.createElement('button');
buttonSet.textContent = "Set True";
buttonSet.onclick = function () {
    privateStuff.setPrivate(true);
}

let buttonGet = document.createElement('button');
buttonGet.textContent = "Get";
buttonGet.onclick = function() {
    console.log(privateStuff.getPrivate());
}
document.body.appendChild(buttonSet);
document.body.appendChild(buttonGet);

setPrivate()não precisa retornar nada, mas por isso não posso testá-lo. Ao criar um teste de unidade, devo refatorar o código?

Se eu estivesse usando TDD, sempre deveria criar métodos que retornam algo apenas para poder testá-lo? Ou estou faltando alguma coisa?

PS Você pode ver e executar o código aqui

Acho que seu equívoco aqui é que um "sujeito em teste" deve ser sempre um método por si só. Mas isso não é verdade, embora alguns métodos possam ser testados sem o uso de outros métodos, o tamanho típico de um SUT é uma classe ou alguns métodos e funções de interação de uma classe. Portanto, se você possui um método que altera o estado interno de um objeto, sempre deve haver alguma alteração visível externamente no comportamento desse objeto (caso contrário, não faria sentido ter o método em primeiro lugar). E em um teste de unidade, você pode validar exatamente esse comportamento.

Por exemplo, digamos que você tenha uma classe NumberFormattercom a responsabilidade de formatar números de ponto flutuante de uma maneira predefinida. Vamos supor que ele contenha um método FormatToString(double d). Vamos assumir ainda que ele tem um método setDecimalSeparator, mas não getDecimalSeparator. No entanto, você pode facilmente escrever um teste se após uma chamada para setDecimalSeparatoro método FormatToStringse comportar da maneira desejada. Esse teste pode ser assim

  var nf = new NumberFormatter();
  nf.setDecimalSeparator(".");
  AssertEqual("12.34",nf.FormatToString(12.34))
  nf.setDecimalSeparator(",");
  AssertEqual("12,34",nf.FormatToString(12.34))

Portanto, este é um teste significativo de setDecimalSeparator, um método sem um valor de retorno.