Tests

[teamikl]

Test framework

the most of those frameworks or libraries supports same.

• TDD/BDD
• test browser JS, but no need for now.
• can test events / async callback is called.
• report multi formats
• support watch file save

So, it's not so important which one to choose.

• gulp friendly
• portable (not require C compiler on windows)

  Test runner and assertion framework

• [x] mocha/chai
• [ ] karma/jasmine2
• [ ] testem
• Additionaly, istanbul for coverage

[teamikl]

I have config issue with gulp-mocha

can't find passes --require test/setup or load ./test/mocha.opts

test does not know global expect and _ (lodash) where test/setup prepare. I should follow standard method.

[teamikl]

I've tried karma/jasmine on win8.1/64 I saw log calling C compiler I am not sure if they has fallback/mingw compatible build config. If they require VC, less portability. pros is karma/jasmine used in AngularJS tutorial, and new version jasmine2 has support test async. (as read their spec)

[teamikl]

After playing chai assertion framework, I note this memo.

property chains

personally, I don't like such long property chain. reasons:

• usually its run-time cost in JavaScript
• often such code throw null pointer exception. (in C++, Java experience)
• in dynamic typed language, Intellisense may not work. (vanilla JS has no type inference)

but think it little deeper.

• the cost can be ignored in test, more readability.
• the framework was designed to be used as chain, like jQuery. they won't return null no worry.

Chai may not be perfect as choice. However, acceptable at least they support all requirements. and comparison take some time resource. if there is reason must switch library (e.g project outdated etc) then will re-open this issue.

Another assertion library, jasmine2 API had camel case naming, its LiveScript friendly.

// Chai
expect(foo).to.be(bar);

// Jasmine
expect(foo).toBe(bar);

# LiveScript/Jasmine
expect(foo).to-be(bar)

dot make a chain but the hyphen in LiveScript will be translated to camel case, that does not make a chain.

Write test in CoffeeScript / LiveScript has another issue, those script use it variable name implicitly. which naming conflict with BDD frameworks provide global function describe and it. but after figure out the issue, we know how to avoid it.

arrow anti pattern

Use CoffeeScript / LiveScript in test, can avoid Arrow Anti Pattern nested closures make this each end of functions.

    });
  });
});

Consider using LiveScript and Jasmine2 can minimize codes, is trade off. Up to the priority, gain maintenance cost of multiple languages and tests. those scripts are easy to learn but sometime tricky.

re-write test to switch the framework is easy, they are almost compatible expect the API naming.

Now, go on with pure JavaScript in this project.

[teamikl]

Coding tips for QA and coverage

if (condA)
  return;
if (condB)
  return;

do_something();

This guard if/return keep indent level does not go to deep. Test case must have 3 patterns at least, when condA false, condB false and pass both. or Coverage will report missing the tests.

if (condA && condB) {
  do_something();
}

Ok for structural application logic, but not for procedural. code is short/compact tho.

• The nest level may go deeper for complex situations.
• Coverage can't report you have no test when condA/condB were false.

When apply it Sure it is not for all cases. its up to the situation / case by case. key point is condA/condB is application logic or not. if they are just null check, should be hidden from the logic layer.

I just note here the coverage viewpoint.