I have a very common function that I have always unit tested in the same way, but I'm wondering if there is a better solution or if it's even possible a code smell is involved. It seems like a very simple case but I have a function that clears the properties of the object. Working in JavaScript, here is a simple example:function Dog(name, owner) {  this.name = name;  this.owner = owner;  this.reset = function() {    this.name = '';    this.owner = '';  };}var puppy = new Dog('Max', 'Timmy');console.log(puppy.name)  // logs Maxpuppy.reset();console.log(puppy.name)  // logs I would normally unit test by setting the properties, calling the clear function, and then asserting that the properties were indeed set back to the defaults or cleared out. The reason I'm asking about such a simple solution is because of the dogma that unit tests should only have 1 assertion. I also think that a reset type function could get way out of hand when it is dealing with a large number of properties (i.e. an object that is meant to store a SPA's state). I'm sure that I am over-thinking this but wanted to get some outside opinion/criticism for something I have been doing the same for many years. I just cannot possibly think of a better way to do this.Another question could be, are unit tests surrounding a reset function necessary? To me they seem to almost just test the language implementation -- similar to a getter/setter property.
How do you unit test a function that clears properties?
javascript;unit testing
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)