Code Climate vs Coveralls: What are the differences?
Developers describe Code Climate as "Automated Ruby Code Review". After each Git push, Code Climate analyzes your code for complexity, duplication, and common smells to determine changes in quality and surface technical debt hotspots. On the other hand, Coveralls is detailed as "Track your project's code coverage over time, changes to files, and badge your GitHub repo". Coveralls works with your CI server and sifts through your coverage data to find issues you didn't even know you had before they become a problem. Free for open source, pro accounts for private repos, instant sign up with GitHub OAuth.
Code Climate belongs to "Code Review" category of the tech stack, while Coveralls can be primarily classified under "Code Coverage".
Some of the features offered by Code Climate are:
- Automated Git Updates- Nothing to install. Code Climate runs everytime you push a new commit.
- Activity Feeds- Up-to-the-minute information so you can see when and how code changes.
- Instant Notifications- Major security and quality changes pushed to where you work: email, Campfire, HipChat, and RSS feeds.
On the other hand, Coveralls provides the following key features:
- Repository Coverage Statistics
- Individual File Coverage Reports
- Line By Line Coverage
"Auto sync with Github" is the top reason why over 68 developers like Code Climate, while over 44 developers mention "Free for public repositories" as the leading cause for choosing Coveralls.
StackShare, Typeform, and thoughtbot are some of the popular companies that use Code Climate, whereas Coveralls is used by Mapbox, Practo, and Kong. Code Climate has a broader approval, being mentioned in 144 company stacks & 48 developers stacks; compared to Coveralls, which is listed in 58 company stacks and 45 developer stacks.
What is Code Climate?
What is Coveralls?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Coveralls?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
The continuous integration process for our Rails backend app starts by opening a GitHub pull request. This triggers a CircleCI build and some Code Climate checks.
The CircleCI build is a workflow that runs the following jobs:
- check for security vulnerabilities with Brakeman
- check code quality with RuboCop
- run RSpec tests in parallel with the knapsack gem, and output test coverage reports with the simplecov gem
- upload test coverage to Code Climate
Code Climate checks the following:
- code quality metrics like code complexity
- test coverage minimum thresholds
The CircleCI jobs and Code Climate checks above have corresponding GitHub status checks.
Once all the mandatory GitHub checks pass and the code+functionality have been reviewed, developers can merge their pull request into our Git
master branch. Code is then ready to deploy!
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.
This is one of the key tools I can't leave out when I'm working on a project, basically it is mandatory for me to use it on my Ruby on Rails projects. I think the price is a little expensive for a "Solo plan" but if you can get your client to pay, it's definitely worth it. You or the future developers that will continue with the project will thank you!
We use it as part of CI process to check code quality, to ensure that we're not inadvertently making common mistakes and can keep the smells and scope of code changes in line and clean. Having this step here should make future support and additions much more efficient and easy to understand.
Code Coverage is an important metric for us as we aim to deliver regular improvements to our platform.
Check duplicate code, complexity and common pitfalls. Code coverage indicator for Github README file.
checking our repo code quality.