How do I "think in QUnit" with my own JavaScript libraries?

Question

How do I "think in Qunit" with my own JavaScript libraries ?

I'm familiar with developing in javascript, but now I'd like to start using Qunit (with my applications in HTML/JavaScript).

I make my own libraries. I use public functions and private functions. I also use asynchronous functions (event listeners and callbacks) similar to jQuery:

var mylib;

(function() {
        //...
})();

I don't know how to organize that. Here are a few questions to clarify the kind of answers I'm seeking:

• How do I unit test private functions?
• How do I combine hundreds of tests?
• In your experience, what's the best method for organizing the tests? Should I use several HTML files? How should I split the tests between JavaScript files?

• Are there QUnit plugins that you recommend for unit testing?

• With GitHub, can I use QUnit automatically when I commit? How do you set that up? Maybe with travis-ci?

• How do I unit test asynchronous functions? Specifically, what if the functions have a link with LocalStorage (HTML5 Storage) and can interact with other pages (like this)? How can I test that? Should I use an object variable instead of the LocalStorage?

I visited the official website http://qunitjs.com/, but I don't think that the documentation is a good starting point.

Pail

Answer 1

Travis-ci is indeed a good way to trigger tests, including for client-side libraries.

The answer "Using Travis-CI for client-side JavaScript libraries?" give a good examples of such tests, in kort/kort/tree/develop/test/client, which includes QUnit in its index.hml file.
The key is to use Grunt.js.

An example of Travis job: kort/kort/jobs/3266208 does include running QUnit.

---

4 years later, update following the bounty:

You can see unit tests maintained overtime in the FredrikNoren/ungit, which uses Travis.

But since you are not on GitHub, you can use alternatives like GitLab-CI (using you very own GitLab CE -- Community Edition -- server if you want)

See more with that approach in "GitLab Frontend testing standards and style guidelines": those best practices applied to the GitLab project itself could by applied to your projects as well.
You can see their unit test policy.

Sporangium

localStorage run with Grunt.js ? – Pail

@HorsSujet That I don't know: I see both used in github.com/artberri/jquery-html5storage for instance. – Sporangium

Using the remote service GitLab: dev.to/ykyuen/a-simple-gitlab-ci-example-doe – Sporangium

Answer 2

I believe the best answer to "How do I unit test private functions?" is:

You test private functions by testing public functions.

That is to say, you don't test private functions directly. You test them by fully testing the public functions that use them (using enough inputs to test edge cases in the private functions).

Theory & best practice talk: This question relates to Abstraction. Public functions do higher level work that necessitates lower level work - often via private functions. The entity accessing the public function - another module in the same software, a developer using the library, someone calling the API, etc. - only cares about what the high-level public function does. They shouldn't need (or be able) to know what the specific implementation is. It's abstracted away from them.

Example time: Say we have a public function that's part of a graphic design library. This function takes Hex color values like "#ff112a" and turns them into general color names like "Red".

Internally, we could use several private functions:

• One to validate the input and trim it to just the number itself (#ff112a -> ff112a)
• One that converts each hex value into something easier to understand (ff -> 100, 11 -> 6.7, 2a -> 16.5)
• One to translate the RGB information into a general color (100% red, 7% green, and 16.5% blue -> "Red")

However, we could also do all of that work in the one public function. Or we could use a different approach using a different set of private functions internally.

The point is that the private functions are private because they contain details that should be hidden from the outside. We don't test those private functions directly so that our tests stay at the level of abstraction of the public function and we don't insist on the internals working in any specific way.

Mccutcheon