Should every method return a value for Unit Testing?

Question

I am learning to create simple Unit tests to eventually (and hopefully) start to do only TDD; for now I am trying to write tests for code already written to see what might cause problems. This is one of them.

Let's say I have this simple class (with 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;        
    }
}

And I use it in this way:

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() does not need to return anything, but because of that I cannot test it. When creating a unit test for it, should I refactor the code?

If I were doing TDD, should I always create methods that return something just to be able to test it? Or I am missing something?

P.S. You can see and run the code here

Answer 1

I guess your misconception here is that a "subject under test" must be always a method on its own. But that is not true, though some methods can be tested without using any other methods, the typical size of a SUT is a class, or some interacting methods and functions of one class. So if you have a method which changes the internal state of an object, there must be always some externally visible change to the behaviour of that object (otherwise it would not make any sense to have the method in the first place). And in a unit test, you can validate exactly this behaviour.

For example, lets say you have a class NumberFormatter with a responsibility to format floating point numbers in a predefined way. Lets assume it contains a method FormatToString(double d). Let's further assume it has a method setDecimalSeparator, but no getDecimalSeparator. Nethertheless you can easily write a test if after a call to setDecimalSeparator the method FormatToString behaves in a desired way. Such a test could look like this

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

So this is a meaningful test of setDecimalSeparator, a method without a return value.