With the impact of COVID-19, but also in general, more and more teams are moving to remote work. We at Codecov think remote work is great! Codecov itself has been remote only from the beginning, and we drew our inspiration from companies like Gitlab, Invision, and 37 Signals.
For engineering teams, remote work can come with increases in focus work and flow state. However, the decision to be remote is not without its potential friction for your code development workflows.
Testing your code and having code coverage across your code base can help with some of the friction of being a remote development team.
Helps Limit Cycles During Code Review
One of the key friction points for remote engineering teams is at the code review stage, in which code author(s) and code reviewer(s) may need multiple cycles of conversation to approve a pull request for merging into the master branch.
We believe code review is in several pieces:
- Is the code well-tested?
- Is the code secure (vulnerability scanning)? Is its usage of open source compliant with relevant licensing?
- Is the code written to the standards of the organization?
- Is the logic of the code understood and an effective way to solve the underlying business need?
It is our opinion that a human code reviewer should really only be doing #4, reviewing the logic of the code.
In a company with co-located employees, some teams do things like “shoulder tapping” or impromptu conversations to circumvent back and forth time of code review.
Distributed teams don’t have that luxury, and especially once time zones are factored in, a code review that may typically take minutes or hours can take hours or days.
As you can see in the infographic above, without Codecov, it may take one or more turns of code review to confirm if a code change in a pull request is well tested.
Codecov automatically surfaces coverage data on what parts of a code contribution are tested (or not), plus coverage removed or added on other parts of code base.
This way, before a code reviewer even begins a code review, step A. “is code well-tested?” is already answered, taking an entire step away from the process and thereby handing back time to both your contributor and code reviewer.
Detect Test Regressions and Unintended Failures
When an engineering team is small, most of the developers probably know most of the code base (which is why Codecov is free for up to 5 users).
That said, once engineering teams start scaling, the dreaded “regression” can come to pass.
Regression testing is defined as “ a type of software testing to confirm that a recent program or code change has not adversely affected existing features.”
For example, you are writing a new module which relies on existing code. An integration between the module and legacy code breaks the existing code.
If the legacy code was well covered with tests, you would pick up this regression during your testing and before the code reached production.
In a distributed team, risk of regressions grows as original authors of the legacy code may or may not be available and next to you as you are testing and shipping the new code.
Sign up or log in now to see how Codecov can help your remote teams deploy more quickly.
