I've heard it said in Java that if your private methods need testing its a sign that those methods should be public methods of another class.
I can't see why this would not also apply to Javascript, other than that Javascript is rarely written in a very pure "OO" way.
For what its worth I find _private methods to be a horrible hack, I'd much rather have true private methods and force the next developer to think about whether they truly want to make that method public in the hope they'd consider restructuring it.
If your testing requires you to change your public API - especially, making its scope larger and more complex - the problem is not with your API, it's with your testing tools.
(Yes, this is a deficiency in Java amongst other languages. You don't want to be e.g. wading through the lower details of font kerning when trying to use an edit box widget, even when those sub-components need individual testing.)
I don't think anything he said means changing the public API. Moving the methods to another class and making them public there does not mean the other class has to be visible to people using the API.
Most of the value of testing comes from giving yourself a use case for the APIs you're building, forcing you to think about what the interface should be in a real way. The actual testing of behaviour is almost a side effect.
(It's certainly not a tooling deficiency as there are tools that allow testing private methods in Java. IME the best developers make an explicit choice not to use them)
Testing at the API level is effectively integration testing for any kind of non-trivial API.
Unit testing has particular value because it avoids m*n problems. But that doesn't necessarily mean that m and n need to be separately addressable entities in your API. But if you unit test at the API level, then you're forced to do that.
For example, consider a web browser widget that's part of a UI framework. A web browser is an enormously complex piece of software with hundreds of individual modules doing various things. But the API at the UI toolkit level is much, much simpler; an URL and a handful of properties and methods relating to history navigation. Trying to unit-test the web browser at the API level would be ridiculous; no less ridiculous than having your testing constraints drive enormous complexity into the developer-facing API.
There are layers of API. The appropriate test for a web browser widget is a UI framework is probably render this page in the web browser widget, render it in an actual web browser, and check that the two look the same.
Inside the web browser code there will be more detailed things that should be tested - internal APIs. But the point is that these are APIs and should be built as such; they will likely need to be used by other people working on the same code. Even if not, you need this level of structure so that you can build comprehensible software. If every class can monkey around in the internals of every other one, you get an unmaintainable mess very quickly.
Comments
I've heard it said in Java that if your private methods need testing its a sign that those methods should be public methods of another class.
I can't see why this would not also apply to Javascript, other than that Javascript is rarely written in a very pure "OO" way.
For what its worth I find _private methods to be a horrible hack, I'd much rather have true private methods and force the next developer to think about whether they truly want to make that method public in the hope they'd consider restructuring it.
If your testing requires you to change your public API - especially, making its scope larger and more complex - the problem is not with your API, it's with your testing tools.
(Yes, this is a deficiency in Java amongst other languages. You don't want to be e.g. wading through the lower details of font kerning when trying to use an edit box widget, even when those sub-components need individual testing.)
I don't think anything he said means changing the public API. Moving the methods to another class and making them public there does not mean the other class has to be visible to people using the API.
Most of the value of testing comes from giving yourself a use case for the APIs you're building, forcing you to think about what the interface should be in a real way. The actual testing of behaviour is almost a side effect.
(It's certainly not a tooling deficiency as there are tools that allow testing private methods in Java. IME the best developers make an explicit choice not to use them)
Testing at the API level is effectively integration testing for any kind of non-trivial API.
Unit testing has particular value because it avoids m*n problems. But that doesn't necessarily mean that m and n need to be separately addressable entities in your API. But if you unit test at the API level, then you're forced to do that.
For example, consider a web browser widget that's part of a UI framework. A web browser is an enormously complex piece of software with hundreds of individual modules doing various things. But the API at the UI toolkit level is much, much simpler; an URL and a handful of properties and methods relating to history navigation. Trying to unit-test the web browser at the API level would be ridiculous; no less ridiculous than having your testing constraints drive enormous complexity into the developer-facing API.
There are layers of API. The appropriate test for a web browser widget is a UI framework is probably render this page in the web browser widget, render it in an actual web browser, and check that the two look the same.
Inside the web browser code there will be more detailed things that should be tested - internal APIs. But the point is that these are APIs and should be built as such; they will likely need to be used by other people working on the same code. Even if not, you need this level of structure so that you can build comprehensible software. If every class can monkey around in the internals of every other one, you get an unmaintainable mess very quickly.