Unit tests should cover logic, and as a matter of fact, reset doesn’t contain any logic – there is no ifs, no switches, no loops in it – basically, no conditional statements of any type.

And yes, it means that testing it sort of boils down to testing JavaScript as such, as you say. Set a, b, and c to empty strings! Have a, b and c been set to empty strings? Good. Good JavaScript!

So, given there’s no logic, why would we want unit test coverage here at all?

I guess we’d wish to have it in order to protect ourselves against the scenario in which you’re adding another property to the class, but then forget to reset it in your reset function.

The problem here is that you would also have to update your unit test to reveal this bug, and if you forgot about updating your reset function, it stands to reason you would have failed to update testReset, too.

Or your little special function that returns all the contents of your singleton, nicely packed for testing purposes.

One possible alternative would be to use reflection (in case of JavaScript, it’s just iterating over properties of course) for resetting all properties in existence, and then only unit test it as a universal utility, even on an arbitrary stub class.

Of course you’re likely to get into more problems if you want to actually preserve the value of some of your properties rather than wipe everything clean.

All in all, it’s a difficult task because that’s a singleton you have to reset. Singletons are notoriously bad for testability.

Misko Hevery devoted a series of articles and presentations to that. See:

• Root cause of singletons (article)

• Singletons are pathological liers (article)

• The Clean Code Talks – “Global State and Singletons” (video)

You are over-thinking the “one assertion” rule/guideline.

The reason for the rule is that a test case should test only one “behaviour” of a class. By testing only one behaviour per test case, you make it much easier on yourself to pinpoint where an error got introduced when a test case starts failing.

The problem is that it is hard to tell when that basic rule of testing only one behaviour is being violated, also because people might disagree what falls under “one behaviour”.
However, in the large majority of cases, the one behaviour that you want to test can be verified with a single assert statement. For that reason, the rule is being stated as “you shall have only a single assert”.
For the minority of cases where a single, indivisible action of the class has multiple outputs and/or side effects (like your reset method), it is perfectly fine to have multiple assert statements. In fact, you are still asserting just one thing, namely that all properties have been cleared.

An alternative approach is two tests, one for each component of your reset function. Or more, if you have more. These would be pretty simple to create.

A key point of tests is to know what is failing when something fails. If you test the “reset” method and it fails you want to know what failed. While not super important in your example, other situations like this might be much less clear which part is failing.

By testing each individual variable, as long as your workflow is writing a failing test when you add new variables, say Breed to your dog, you will be forced to add Breed to the reset function because you immediately have a failing test.

Probably instead of deciding based on some authorities view of best practices, it’s better to remember why you are writing unit tests – such as you want to save time later by catching bugs early in development, prevent bugs from reaching users, and document the code for developers (and possibly for others).

The deciding principle, then, is whether the time spent writing the tests is justified in achieving those goals. Of course, this is still a guess based on limited information, but that’s the best that can be done.

How long will it take you to figure out the actual bug if you write one test versus N tests? Which way will be more stable in the face of changing requirements? In this case I personally would estimate that writing a large number of tests probably won’t be worth the time, plus the semantics of “clearing out the properties” apparently implies that it should clear out future properties as well. Note that this could technically be written in a single assertion anyway, for example:

assert.isTrue(myLibrary.propertyCollection(objectUnderTest).All(function(x) {x==='';}));

Whether this makes sense in your situation is something you can answer better than I can.

You could add a function that returns the properties in their default state enclosed in an object and then another that returns their current state. Compare the returning values of each of those functions and assert accordingly.

In this particular example, you should be able to assert true that puppy.reset().getNameAndOwner() should be equal to puppy.getDefaultState(). (There’s a link for Object comparison at the bottom of my post. Do NOT use == or ===)

See below

function Dog(name, owner) {
   this.name = name || '';
   this.owner = owner || '';

   this.reset = function() {
       this.name = '';
       this.owner = '';
   };

   this.getNameAndOwner = function() {
       var name = this.name
           owner = this.owner;
       return { name: name, owner: owner };
   }

   this.defaultState = function() {
       var emptyName = '',
           emptyOwner = '';
       return { name: emptyName, owner: emptyOwner };
   }
}

How to compare objects:

Object comparison in JavaScript
How to determine equality for two JavaScript objects?