Codecov

We use Codecov because it's a lot better than Coveralls. Both of them provide the useful feature of having nice web-accessible reports of which files have what level of test coverage (though every coverage tool produces reasonably nice HTML in a directory on the local filesystem), and can report on PRs cases where significant new code was added without test coverage.

That said, I'm pretty unhappy with both of them for our use case. The fundamental problem with both of them is that they don't handle the ~1% probability situations with missing data due to networking flakiness well. The reason I think our use case is relevant is that we submit coverage data from multiple jobs (one that runs our frontend test suite and another that runs our backend test suite), and the coverage provider is responsible for combining that data together.

I think the problem is if a test suite runs successfully but due to some operational/networking error between Travis/CircleCI and Codecov the coverage data for part of the codebase doesn't get submitted, Codecov will report a huge coverage drop in a way that is very confusing for our contributors (because they experience it as "why did the coverage drop 12%, all I did was added a test").

We migrated from Coveralls to Codecov because empirically this sort of breakage happened 10x less on Codecov, but it still happens way more often than I'd like.

I wish they put more effort in their retry mechanism and/or providing clearer debugging information (E.g. a big "Missing data" banner) so that one didn't need to be specifically told to ignore Codecov/Coveralls when it reports a giant coverage drop.

Codecov Although I actually use both codecov and Coveralls, I very much like the graphs I get from codecov, and some of their diagnostic tools.

I use Codecov because it's easy to integrate in Github PullRequests which enables a grpahical view from the code coverage.

We chose Vue.js at Codecov to replace a front end that was based mostly on server side rendered Python templates, and was getting fairly long in the tooth. The move to Vue.js allowed us to take a more component driven approach to our front end, providing greater flexibility and reuse when creating new pages and refactoring old ones. Another bonus was how easily we could integrate Axios with VueJS for making AJAX calls within Vue.js components and their associated vuex stores. We were also able to easily integrate Vue.js with the Jest testing framework, which allowed to provide test coverage for a front end where none previously existed.

The move to Vue.js has allowed us to be more agile in our front end development by further decoupling our front end from our back end. Additionally, by fully embracing a component-driven approach, we're able to more easily isolate and test functionality, leading to a more readible, maintainable, and extensible front end codebase.