Testicular pain

[bnhovde]

I've hit a hurdle getting the testing off the ground and thought I'd share my thought process here in case you're interested or have any input.

First of all, does anyone have any preferences in terms of testing frameworks? The tutorial basis for this setup used mocha & chai, so that's what's in place now, but I have no strong ties to either.

From previous experience I'm aware that testing DOM manipulation can be tricky. The below quote comes from stack overflow and seems to be the accepted approach:

One of the toughest parts of javascript unit testing is not the testing, it's learning how to architect your code so that it is testable.

You need to structure your code with a clear separation of testable logic and DOM manipulation.

My rule of thumb is this:

If you are testing anything that is dependent on the DOM structure, then you are doing it wrong.

In summary: Try to test data manipulations and logical operations only.

This all makes our lives a little harder since so much of building an UI library depends upon DOM interaction. Right off the bat my dialog module throws a few errors since I'm referencing the DOM to attach the required functionality:

Running npm test gives ReferenceError: document is not defined due to several document.querySelector's in the dialog.js file. I can get around this, but I'm more curious about what y'all think about this, and what direction we should take.

I think we have 2 options:

1: Stick with testing internal module functionality without touching the DOM. 2: Implement some js-based browser the likes of phantomJS and test DOM interaction that way.

There might be things I've overlooked here. Anyway, this is where I'm at. Would love to hear your thoughts.

[DaveOrDead]

I have no preference on framework, just something that's easy to use.

We'll probably need some sort of headless browser like PhantomJS like you say

[chris-pearce]

No preference either, let's just pick one and get this one closed 😄.