How to Test Private Functions in JS Modules
engineering.clever.com
How to Test Private Functions in JS Modules
1–10 of 19 posts
Re: How to Test Private Functions in JS Modules
#2Very cool solution! I've also seen claims that the private methods of modules should not be tested, since they don't represent the public interface of the module and refactorings are likely to change the private methods. If the private methods are complicated enough to warrant testing on their own, ideally they should be extracted into their own module. Not sure if I agree but it's something to think about!
Re: How to Test Private Functions in JS Modules
#3If you really want to buy into the module pattern, it seems like anything that's enough of a unit that you'd want to test could be in its own module.
In the example given, the sum function could be its own module that you require into the stats module. That way you could test them independently, and the stats module could simply expose its own appropriate methods.
This has the added benefit of making the sum function reusable.
Personally I prefer this approach to introducing environmental concerns into your code.
Re: How to Test Private Functions in JS Modules
#4If you really want to buy into the module pattern, it seems like anything that's enough of a unit that you'd want to test could be in its own module. In the example given, the sum function could be its own module that you require into the stats module. That way you could test them independently, and the stats module could simply expose its own appropriate methods. This has the added benefit of making the sum function…
That's a great point. I definitely agree that erring on the side of modules is better. I just worry about times when the purpose of a module is not clearly defined at the outset (e.g. when it only contains one function that is only used in one other module). I have often seen that devolve into the "helper" module, where random functions collect.
I'm also not sure I buy the assertion that all code you would want to test is code you would want to export publicly. Do you have any reasoning to support that idea?
Re: How to Test Private Functions in JS Modules
#5Very cool solution! I've also seen claims that the private methods of modules should not be tested, since they don't represent the public interface of the module and refactorings are likely to change the private methods. If the private methods are complicated enough to warrant testing on their own, ideally they should be extracted into their own module. Not sure if I agree but it's something to think about!
What if the private methods are complex but also module-specific? For instance, if they deal with a data type that is private to the module?
When you pull out complex code like this into another module, how do you specify that the new module is actually private to the old module?
Re: How to Test Private Functions in JS Modules
#6Very cool solution! I've also seen claims that the private methods of modules should not be tested, since they don't represent the public interface of the module and refactorings are likely to change the private methods. If the private methods are complicated enough to warrant testing on their own, ideally they should be extracted into their own module. Not sure if I agree but it's something to think about!
What if the private methods are complex but also module-specific? For instance, if they deal with a data type that is private to the module? When you pull out complex code like this into another module, how do you specify that the new module is actually private to the old module?
[deleted]
Re: How to Test Private Functions in JS Modules
#7Very cool solution! I've also seen claims that the private methods of modules should not be tested, since they don't represent the public interface of the module and refactorings are likely to change the private methods. If the private methods are complicated enough to warrant testing on their own, ideally they should be extracted into their own module. Not sure if I agree but it's something to think about!
(They are very good points though! Thanks for sharing them)
Re: How to Test Private Functions in JS Modules
#8Very cool solution! I've also seen claims that the private methods of modules should not be tested, since they don't represent the public interface of the module and refactorings are likely to change the private methods. If the private methods are complicated enough to warrant testing on their own, ideally they should be extracted into their own module. Not sure if I agree but it's something to think about!
"Private methods of modules should not be tested, since they don't represent the public interface of the module and refactorings are likely to change the private methods"
+1 to that.
Re: How to Test Private Functions in JS Modules
#9I gave a lightning presentation on this subject last month. A better solution is to put the private methods into (sub)modules. This makes them public to the file system and gives you the ability to tune what you make public via your module API. Ideal for testing purposes and good for module structure in my opinion. The slides can be found here: https://speakerdeck.com/qubyte/writing-testable-private-meth...
Re: How to Test Private Functions in JS Modules
#10I gave a lightning presentation on this subject last month. A better solution is to put the private methods into (sub)modules. This makes them public to the file system and gives you the ability to tune what you make public via your module API. Ideal for testing purposes and good for module structure in my opinion. The slides can be found here: https://speakerdeck.com/qubyte/writing-testable-private-meth...
P.S. see option 3 in that presentation.