Lev Vereshchagin

cmp-cov: Track Python test coverage during refactoring

2026-04-27T17:23:00+03:00

When test coverage isn't 100%, it's hard to track how it changes during refactoring. I used to either ignore it or copy the coverage section and diff it by hand in VS Code. Diffs like this had to be eyeballed (and I only added a single test here! — this is a toy example):</p>

13c13</span></span>
<</span> chatbotfront/api/rest/system.py                                  9      1    89%   14</span></span>
---</span></span>
></span> chatbotfront/api/rest/system.py                                  9      0   100%</span></span>
62c62</span></span>
<</span> tests/api/test_system.py                                         3      0   100%</span></span>
---</span></span>
></span> tests/api/test_system.py                                         7      0   100%</span></span>
92,93c92,93</span></span>
<</span> TOTAL                                                         2388    105    96%</span></span>
<</span> ==================================== 208 passed in 44.62s =====================================</span></span>
---</span></span>
></span> TOTAL                                                         2392    104    96%</span></span>
></span> ==================================== 209 passed in 44.35s =====================================</span></span>
</span></code></pre>
To make such checks easier and more humane, I wrote a tool — cmp-cov</a>. It compares the current coverage against a saved baseline. Example usage:</p>
❯</span> uv</span> run</span> pytest</span> -</span>-cov</span> &&</span> uvx</span> cmp-cov</span> save-baseline</span></span>
#</span>...pytest output...</span></span>
Saved</span> baseline</span> '</span>default</span>'</span> for</span> /Users/lev/web/chat/bot/front</span></span>
  path:</span>    /Users/lev/.cache/cmp-coverage/%2FUsers%2Flev%2Fweb%2Fchat%2Fbot%2Ffront/default/coverage.xml</span></span>
  sources:</span> 85</span> files</span> in</span> /Users/lev/.cache/cmp-coverage/%2FUsers%2Flev%2Fweb%2Fchat%2Fbot%2Ffront/default/sources</span></span>
  total:</span>   95.69%</span></span></code></pre>
Add new test, and run again, this time diff:</p>
❯</span> uv</span> run</span> pytest</span> -</span>-cov</span> &&</span> uvx</span> cmp-cov</span> diff</span></span>
#</span>...pytest output...</span></span>
Project:</span>  /Users/lev/web/chat/bot/front</span></span>
Baseline:</span> '</span>default</span>'</span> (/Users/lev/.cache/cmp-coverage/%2FUsers%2Flev%2Fweb%2Fchat%2Fbot%2Ffront/default/coverage.xml</span>)</span></span>
Saved:</span>    2026-04-27</span> 17:16:58</span></span>
</span>
Total:</span> 95.69%</span> →</span> 95.69%</span> (+0.00</span>)</span></span>
</span>
↑</span> uncovered</span> →</span> covered</span> (1</span> lines,</span> 1</span> runs</span>):</span></span>
  chatbotfront/api/rest/system.py:14</span></span>
</span>
+</span> new</span> covered</span> (4</span> lines,</span> 1</span> runs</span>):</span></span>
  tests/api/test_system.py:7-10</span></span></code></pre>
Now it's clear what changed in coverage.</p>
There's a similar tool, diff-cover</code></a>, but it only shows coverage for lines changed in a git diff. I needed to compare coverage before and after, as the code itself changes.</p>

Source code: github.com/vrslev/cmp-cov</a>.</p>
You can try it this way: uvx cmp-cov save-baseline</code>, change some code, then uvx cmp-cov diff</code>.</p>



Survival in IT
2026-01-13T10:48:48+03:00
Specialists earn more than manual workers at the cost of fragility and the risk of becoming non-competitive:</p>

[...] a specialist has acquired a lot of specialized knowledge at a cheap unit cost in order to be competitive. However, given the low unit cost, this knowledge is not a solid basis for further professional growth; rather, it's expendable. The means to survival for a specialist is his ability to rapidly learn new subjects, quickly produce saleable works, and then move on. This is called skimming. It's the same strategy pursued by weeds, to use an ecological analogy. At the expert level (see Gauging mastery), a person needs 80-100 hours a week to stay competitive. For masters level, it's 60-80 hours, and to remain competent requires 40-60 hours a week.</p>
</blockquote>
— Jacob Lund Fisker, book "Early Retirement Extreme"</em>



To remain competitive in IT, you clearly don't need 80–100 hours per week—that's overkill. But the general message is quite interesting (even if somewhat clichéd).</p>
How not to end up in a bad position? Overall, the advice is also quite clichéd, here's what ChatGPT says:</p>



Knowledge becomes obsolete quickly.
Technical skills in development are "cheap units of knowledge": language, framework, approach. In 2–5 years, much needs to be relearned.</p>
</li>

The key skill is fast learning.
Developers constantly forget the old and retrain for new technologies. Specialization doesn't provide a stable foundation; it's important to be able to adapt.</p>
</li>

Competition is not only based on skills.
When many reach the required level, hiring decisions rely on secondary factors: communication, "fit", presentation, stress resistance.</p>
</li>

Career is a pyramid, not a ladder.
There are fewer positions at higher levels, and growth depends not only on competence. It's easy to end up in a role where it's difficult to be competent (Peter Principle).</p>
</li>

Burnout is a systemic risk.
Specialists who identify themselves with one technology suffer more when the market changes or knowledge becomes devalued.</p>
</li>

Survival strategy — meta-skills.
It's more valuable not to "know Django," but to be able to:</p>

learn quickly</li>
think architecturally</li>
understand system principles</li>
effectively use AI tools</li>
develop soft skills</li>
</ul>
These are things that become obsolete the slowest.</p>
</li>

IT is essentially about adaptation.
A developer is successful when not tied to a tool, but able to solve problems and switch between technologies without pain.</p>
</li>
</ol>
</blockquote>


View Transitions and Speculation Rules
2025-12-30T14:31:34+03:00
It's nice to see how modern CSS features are changing web development: It's time for modern CSS to kill the SPA - Jono Alderson</a></p>
View Transitions and Speculation Rules seem great for simple websites. They offer native browser solutions for smooth navigation and performance optimization without the complexity of SPAs. In fact, vrslev.com already uses Speculation Rules for faster page loads.</p>


Every augmentation is also an amputation
2025-12-28T16:31:11+03:00
Most technology is a double-edged sword:</p>

Speaking of the effects of technology on individuals and society as a whole, every augmentation is also an amputation</strong>.</p>
</blockquote>
— Neal Stephenson</a>, Remarks on AI from NZ via Simon Willison</a></p>


Automatically annotate Python functions with a single VS Code shortcut
2025-07-24T00:49:28+03:00
I watched this video</a> by Anthony Sottile</a> about a neat tool for auto-generating function annotations: auto-type-annotate</a>. It is actually inspired by unmaintained tool called PyAnnotate</a>.</p>
Inspired by it, I added</a> a custom VS Code shortcut: now when I press Cmd+K, then Cmd+M, annotations magically appear on [some] functions!</p>


Simple DSLs That Work
2025-07-08T14:34:43+03:00
A year ago, I released auto-typing-final</a>, a fixer and linter enforcing Raiffeisenbank Russia Python Community style-guide</a> rule to “use typing.Final</code> for constants.” It’s now integrated throughout our codebase (there’s even a VS Code extension).</p>
Inspired by Ty’s work on Ruff</a> and Carl Meyer’s Markdown-based test framework PR in Ruff</a>, which demonstrated how embedding example-driven tests in Markdown can simplify both testing and documentation.</p>
To streamline both tests and documentation, I introduced</a> a simple Markdown-based internal DSL for defining transformation scenarios inline:</p>
###</span> Multiple Assignments with </span>`</span>Final</span>`</span></span>
</span>
```</span>python</span></span>
a</span>:</span> Final</span> =</span> 1</span>  #</span> remove ("remove" means that "Final" should be stripped out. There's also "insert"—the opposite)</span></span>
a</span> =</span> 2</span></span></code></pre>
Such examples replaced complex parametrization with multi-line strings.</p>
Why This Internal DSL Works:</strong></p>


Enhanced Clarity. Headings describe each test case, and fenced code blocks separate input, expected changes, and annotations.</p>
</li>

Single Source of Truth. The same Markdown snippet powers pytest parameterization and user-facing documentation.</p>
</li>
</ul>
So...#</a>
</h2>
Small DSLs like this work well: they’re easy to parse, easy to read and easy to write.
This showcase proves that sometimes the simplest tools have great impact.</p>


Declarative Homebrew
2024-05-14T14:51:08+03:00
I want to keep my development environment consistent across both my work and personal MacBooks. (That's why I use</a> mise and have</a> dotfiles repository.)</p>
One thing that didn't sit well with me about the process was keeping my Homebrew installations up to date. Presiously, I had used the make dump</code> command that I would run occasionally to update Brewfile with brew bundle dump</code>. The problem was that it always lagged behind the actual state of my machine.</p>
Now, I have Fish function that updates Brewfile every time I run a potentially destructive brew command:</p>
function</span> brew</span></span>
  command</span> brew </span>$</span>argv</span>; </span>and</span>\</span></span>
  switch</span> $</span>argv</span>[</span>1</span>]</span></span>
    case</span> install uninstall reinstall tap untap</span></span>
      brew</span> bundle dump</span> --file</span> $</span>DOTFILES_ROOT</span>/Brewfile</span> --force</span></span>
  end</span></span>
end</span></span></code></pre>


mise-en-place: dev env in a world with cargo
2024-05-11T09:46:33+03:00
A couple of days ago I discovered mise</a> (pronounced "meez"). It's a polyglot tool version manager similar to asdf or pyenv, and an environment manager, like direnv, that is fast, reliable, has a declarative configuration and feels as good as cargo.</p>
I got rid of hatch</a> which I had previously been using only for downloading Pythons from python-build-standalone</a> with the command hatch python install all --update</code></a>. I have also stopped using Node from Homebrew, and removed custom scripts from my dotfiles that were used to keep pipx installations synchronized between my work and personal laptops.</p>
My ~/.config/mise/config.toml</code> now looks like this:</p>
[</span>tools</span>]</span></span>
python</span> =</span> [</span>"</span>3.12</span>"</span>,</span> "</span>3.11</span>"</span>,</span> "</span>3.10</span>"</span>,</span> "</span>3.9</span>"</span>,</span> "</span>3.8</span>"</span>]</span></span>
node</span> =</span> "</span>lts</span>"</span></span>
usage</span> =</span> "</span>latest</span>"</span>  #</span> required by mise itself</span></span>
"</span>pipx:maturin</span>"</span> =</span> "</span>latest</span>"</span></span>
"</span>pipx:poetry</span>"</span> =</span> "</span>latest</span>"</span></span>
"</span>pipx:pypi-command-line</span>"</span> =</span> "</span>latest</span>"</span></span>
"</span>pipx:watchfiles</span>"</span> =</span> "</span>latest</span>"</span></span>
</span>
[</span>settings</span>]</span></span>
experimental</span> =</span> true</span>  #</span> pipx backend is experimental</span></span></code></pre>
I have also started using mise's environment management feature. I placed the .mise.local.toml</code> file containing organization-specific environment variables in the folder with work repositories:</p>
[</span>env</span>]</span></span>
PIP_INDEX_URL</span> =</span> "</span>...</span>"</span></span>
CERT_PATH</span> =</span> "</span>...</span>"</span></span>
GITLAB_TOKEN</span> =</span> "</span>...</span>"</span></span>
...</span></span></code></pre>
Everything is great so far.</p>


Intro 🎉
2024-02-02T20:16:52+03:00
Hi there! 👋</p>
My name is Lev, I'm a self-taught software developer from Russia. I'll be starting my first job in one week and I am excited to be exposed to many new things. That's why I decided to document my learnings in a TIL (Today I Learned) format about.</p>
Stay tuned for more updates, see you soon!</p>

Lev Vereshchagin

cmp-cov: Track Python test coverage during refactoring

Survival in IT

View Transitions and Speculation Rules

Every augmentation is also an amputation

Automatically annotate Python functions with a single VS Code shortcut

Simple DSLs That Work

So...#</a> </h2> Small DSLs like this work well: they’re easy to parse, easy to read and easy to write. This showcase proves that sometimes the simplest tools have great impact.</p>

Declarative Homebrew

mise-en-place: dev env in a world with cargo

Intro 🎉

So...#</a> </h2>
Small DSLs like this work well: they’re easy to parse, easy to read and easy to write. This showcase proves that sometimes the simplest tools have great impact.</p>