Answer the question
In order to leave comments, you need to log in
How to write a qunit test for private functions hidden behind a screen?
Good night all.
I'm learning qunit. From the very beginning, one question was of interest: what is the best practice for testing systems in which 90% of the code is hidden from access by an ordinary user (for example, a plugin)? After all, the standard scheme is as follows:
- we include qunit.js \ css
- we include scripts.js, with the plugin \ scripts that we are testing
- we include the tests themselves
At the same time, I did not find any tools to test a private method that is not accessible from the outside - this is impossible in the way how other, public functions are tested. And I see several options for solving the problem:
- keep 2 versions: dev (with methods available from outside), and production build
- write tests directly inside our script.js (qunit allows you to run tests in a chain), in my opinion - a dirty solution, but better than keeping a special version with externally accessible methods
. Yes, and there are some other issues covered.
I would be grateful for tips on the right track, thanks in advance.
PS I came across an article about Jasmine, which confirms the second option. But doesn't this approach leave some of the functions uncovered by tests?
Answer the question
In order to leave comments, you need to log in
I've read that private methods are implementation details and shouldn't be covered by tests. In essence, unit tests are written to capture some kind of contract that your code exposes to the outside. Private methods, by definition, are not included in this contract.
In practice, if you want to cover some library with tests, you can do this: create index.js and separate files to your liking, all in the CommonJS module format. index.js requires all files and makes module.exports things that should be public. The tests require files individually. Thus, the library as a whole exposes only the public interface to the outside, but the internal mechanics is covered by tests. Optionally, CommonJS are replaced with generic modules .
Private functions are not tested. But who will forbid if you really want :). In this case, you can create a mechanism for accessing private functions and test it.
What's not to like about building separately for sales and testing?
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question