Test Coverage: How to improve?

[rxaviers]

How can we improve our test coverage? What test suites can we import (e.g., ECMA-402, google cldr implementation)?

• http://js.i18nqa.com/
• https://github.com/perl-cldr/cldr-number-pm5/tree/master/t
• https://github.com/twitter/twitter-cldr-rb/tree/master/spec/formatters/numbers
• https://github.com/twitter/twitter-cldr-rb/blob/master/spec/parsers/number_parser_spec.rb

How to improve test coverage reports?

• grunt-qunit-instanbul

[jzaefferer]

Let's try replacing grunt-contrib-qunit with grunt-qunit-istanbul to get coverage reports.

We should import at least one existing testsuite before releasing 1.0.

[rxaviers]

Reference:

• http://js.i18nqa.com/

[jzaefferer]

Is there a source repo behind that site? It isn't using QUnit properly, it should set autostart = false and run QUnit.start() before running test() calls.

[rxaviers]

For the record, see https://groups.google.com/forum/#!topic/javascript-globalization/-eq6E9lDHHg for a follow up (where @jzaefferer asks them the above questions).

[jzaefferer]

There's this perl implementation of a number formatter, with tests: https://github.com/perl-cldr/cldr-number-pm5/tree/master/t

Some of those tests are adapted from https://github.com/twitter/twitter-cldr-rb/tree/master/spec/formatters/numbers

That project has a lot more, like https://github.com/twitter/twitter-cldr-rb/blob/master/spec/parsers/number_parser_spec.rb

[rxaviers]

Added those to the description of this issue as well. Thanks

[patch]

A few notes about the tests for cldr-number-pm5 and twitter-cldr-rb: At the time that I started writing the tests for CLDR::Number in 2013, I looked for existing test suites and there were only a few options back then, notably ICU and TwitterCldr. The ICU tests were a big pain to work with and had so much C code throughout them that it seemed like too much work to port into Perl tests. The TwitterCldr tests, on the other hand, used a nice test framework, the tests were easily readable, and I could quickly port them. As I implemented functionality and made sure that it conformed to UTS#35, I had to increasingly change the tests that were based on TwitterCldr because it turned out that many didn't conform to the spec. One example that comes to mind is percent formatting, where the spec says that you pass the value 0.05 to be formatted as 5% but TwitterCldr expects you to pass the value 5. I just wanted to point this out because any one implementation might have a number of things that either don't conform to the spec or are not yet implemented and shouldn't be taken as the gold standard.

[rxaviers]

Very true. Thanks for sharing these insights.