Increased code-coverage for choropleth

[aashish24]

No description provided.

[codecov-io]

Codecov Report

Merging #676 into master will increase coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #676     +/-   ##
=========================================
+ Coverage   90.64%   90.75%   +0.1%     
=========================================
  Files          84       84             
  Lines        8736     8736             
=========================================
+ Hits         7919     7928      +9     
+ Misses        817      808      -9

Impacted Files	Coverage Δ
src/choroplethFeature.js	98.79% <ø> (+10.84%)	✅

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a210c07...2a264c4. Read the comment docs.

[manthey]

I notice that we still have one line uncovered; that of direct creation. This can be tested like so:

    it('direct creation', function () {
      var map, layer, choropleth;
      map = create_map();
      layer = map.createLayer('feature', {renderer: 'vgl'});
      choropleth = geo.choroplethFeature({layer: layer});
      expect(choropleth instanceof geo.choroplethFeature).toBe(true);
    });

[aashish24]

it('direct creation', function () {
var map, layer, choropleth;
map = create_map();
layer = map.createLayer('feature', {renderer: 'vgl'});
choropleth = geo.choroplethFeature({layer: layer});
expect(choropleth instanceof geo.choroplethFeature).toBe(true);
});

I was wondering about that but i realized that we don't do that in general. I can add this snippet.

Also, I realized that sometimes the GL headless tests are failing on travis. It seems random to me and related to failed download but i have not looked closely.

[manthey]

In many of the unit tests we create the feature explicitly for some of the tests, so this gets tested as part of that (e.g., the polygonFeature tests).

There are some speed tests that occasionally fail. These are set to be pretty low, but they still sometimes fail; we could set the threshold even lower, or try to run them up to n times to see if they pass. In theory, if we make some change that affects our speed, then these should pick that up.

Also, it looks like some package was recently changed so that we may now need a more recent version of npm to run tests.

[aashish24]

Also, it looks like some package was recently changed so that we may now need a more recent version of npm to run tests.

that could be. It was trying to download a package and failed last time I saw the log

[aashish24]

@manthey this is ready for review . The gl tests are failing but that is because of the other issues which I think you are taking care of in your #677 branch.

[manthey]

Travis is running slowly today. I've submitted PR #679 to fix the node version and to relax some timing requirements. Hopefully once that passes and merges in, this will pass, too.

[aashish24]

Branch is updated with recent changes from master that should fix the travis tests.

[aashish24]

@manthey looks like we still have some the timing issue with glLineOpts..but I will merge this branch since it seems orthogonal to my changes as you approved it.

[manthey]

Agreed.