Great article. I have a similar process, described here: https://www.dein.fr/posts/2026-01-08-write-and-checkout-the-...
556 karma · joined April 26, 2011
http://www.d3in.org/
Editing and manipulating CSV by hand is a pain. Something like a simplified sqlite viewer/editor?
GensDeConfiance is a community accessible only via referrals, with about 800k members (mostly in France). Our main product is our classifieds website. It's free and pretty much guaranteed to be scam-free!
We have a bunch of roles available: Infra Engineer, Senior Data Engineer, Senior Back-end Engineer. Our stack: back-end in PHP/Symfony/Python, front-end in TypeScript, React and React Native, data infra in Python. We deploy on Docker, AWS (managed via terraform).
Most of our roles are described here: https://www.welcometothejungle.com/fr/companies/gens-de-conf...
We are only looking at onsite roles for now. You need to be authorized to work in France.
We'd love to hear from you. Contact me at charles@gensdeconfiance.com ;)
GensDeConfiance is a community accessible only via referrals, with about 700k members (mostly in France). Our main product is our classifieds website. It's free and pretty much guaranteed to be scam-free!
We have a bunch of roles available: Infra Engineer, Senior Data Engineer, Back-end Engineer, Front-end Engineer. Our stack: back-end in PHP/Symfony, front-end in TypeScript, React and React Native, data infra in Python. We deploy on Docker, AWS (managed via terraform).
Most of our roles are described here: https://www.welcometothejungle.com/fr/companies/gens-de-conf...
We are only looking at onsite roles for now. You need to be authorized to work in France.
We'd love to hear from you. Contact me at charles@gensdeconfiance.com
GensDeConfiance is a classified ads site accessible by referral. It's free and pretty much guaranteed to be scam-free!
We have a bunch of roles available: Infra Engineer, Senior Data Engineer, Back-end Engineer, Front-end Engineer. Our stack: back-end in PHP/Symfony, front-end in React and React Native, data in Python. We deploy on Docker, AWS (managed via terraform).
Some of our roles are described here: https://www.welcometothejungle.com/fr/companies/gens-de-conf...
We are only looking at onsite roles for now.
We'd love to hear from you. Contact me at charles (at) gensdeconfiance.com
Thanks for the detailed answer! I have answered some of your points and some of the points made in the comments below in the article.
The article might have been perceived as more dogmatic than it meant to be. It is actually, I believe, a pretty pragmatic position. I tried to clarify the wording here and there, let me know if you still disagree with the point I'm making.
### 100% test coverage does not mean you're testing everything right.
Absolutely - this point is explicitly stated in this article. I even give an example situation showing how just checking the test coverage leads to missing an important test.
100% test coverage does not make your code invulnerable, and it should evidently not be your only metric. This article is only about the test coverage metric.
### A test suite that covers 80% is pretty good
Absolutely. It is a good number and a good goal for any codebase.
However, what about that remaining 20 %? Why are they not tested? Will it be clear in 2 months why they were not tested? In 6 months? In a year? While it may make perfect sense not to test them, you should be explicit about that decision and keep the reason in the code.
If you don't keep the test coverage _metric_ at 100%, then you leave it up to the code reviewer to challenge your test coverage assumption.
### 100% is a blanket rule that leaves no room for negotiation
Once again, the goal is not to cover 100% of the lines of code - it would be almost impossible. Thanks to `no cover` markers, you can still decide to exclude code from coverage. It actually makes this negotiation explicit in the code, as opposed to implicit during the code review phase coverage.
Consider the example below:
def toast(bread: str) -> str:
if toast == "brioche":
raise ValueError("...")
With an explicit marker, the intent is clear and gives you insight with what is considered appropriate coverage for _this_ codebase:
def toast(bread: str) -> str:
if toast == "brioche": # pragma: no cover, trivial error case
raise ValueError("...")
Right, that's probably the case. However, this is not different from proper testing, monitoring, logging practices. Decide if it's important, then start with something attainable that brings you closer to the goal, and iterate.
Also, if it is not a desirable goal for the codebase, then for sure don't monitor test coverage!
### Enforcing 100% test coverage leads to bad tests
It bears repeating: this is not about testing 100% of the lines; this is about keeping the code coverage metric at 100%. I am not sure how that would lead to bad tests.
Putting too much focus on one particular metric might lead to gaming behavior. That does not mean that no metric you should be enforced. I believe that there isn't enough material and training about what it takes to write good tests. This is beneficial regardless of whether you enforce test coverage. Also, the more you talk about test coverage, the more you iterate and learn about what it takes to write good tests in your language and codebase.
What's sure is that it is straightforward to write bad tests. It takes a lot of skills, experience, and hygiene to write great, maintainable tests. That's a topic for another article.
### 100% coverage only matters for languages without a type checker
No. Sure, a type checker might catch some classes of bugs that would require a test in a language without type checking, but you still need to test correctness (among others).
### You're creating blind spots
Unless you're reviewing your test coverage report after every single commit, leaving explicit markers in the code and keeping the metric at 100% is actually a much safer practice.
When working in code that has been excluded, you'll immediately see the `no cover` marker, perhaps with a comment explaining why the code is excluded. This lets you reconsider the coverage decision.
Any regression in coverage will break the tests.
### You should not exclude code from coverage because of setup cost
This article is not about end-to-end vs. unit testing. I have provided some examples of code that I sometimes exclude from testing, but your mileage may vary.
It starts with a few high-level book recommendations, and blog articles for more specific topics.
My favorite book, which has not been listed in this thread, is: Turn the Ship Around!: A True Story of Turning Followers into Leaders. David Marquet, who used to command a nuclear submarine, explains how he achieved high levels of motivation and output thanks to empowering his team.
I think it provides a pretty comprehensive list of topics that you could chat about during your interviews. Rather than making a good impression, you should talk truthfully about those topics. Worst case you'll learn something about them. Management is a great role that requires constant learning.
Good luck for the interviews!
Uber's Amsterdam engineering office is looking for back-end, Android and iOS engineers for its teams:
* Payments: do you want to build the future of payments for on-demand services?
* Mobile platform: are you passionate about tooling that makes developer more productive?
Learn more about our openings on https://join.uber.com/amsterdam-engineering
Learn more about the teams on https://eng.uber.com/amsterdam-team-profile/
Email charles@uber.com if interested!
Uber's Amsterdam engineering office is looking for back-end, Android and iOS engineers for its teams:
* Payments: do you want to build the future of payments for on-demand services? * Mobile platform: are you passionate about tooling that makes developer more productive?
Learn more about our openings on https://join.uber.com/amsterdam-engineering
Learn more about the teams on https://eng.uber.com/amsterdam-team-profile/
Email charles@uber.com if interested!
Uber's Amsterdam engineering office is looking for back-end, Android and iOS engineers for its teams:
* Payments: do you want to build the future of payments for on-demand services? * Mobile platform: are you passionate about tooling that makes developer more productive?
Learn more about our openings on https://join.uber.com/amsterdam-engineering
Learn more about the teams on https://eng.uber.com/amsterdam-team-profile/
Email charles@uber.com if interested!
Uber's Amsterdam engineering office is looking for back-end, Android and iOS engineers for its teams:
* Payments: do you want to build the future of payments for on-demand services? * Mobile platform: are you passionate about tooling that makes developer more productive?
Learn more about our openings on https://join.uber.com/amsterdam-engineering
Learn more about the teams on https://eng.uber.com/amsterdam-team-profile/
Email charles@uber.com if interested!
Uber's Amsterdam engineering office is looking for back-end, Android and iOS engineers for its teams:
* Payments: do you want to build the future of payments for on-demand services? * Mobile platform: are you passionate about tooling that makes developer more productive?
Learn more about our openings on https://join.uber.com/amsterdam-engineering
Learn more about the teams on https://eng.uber.com/amsterdam-team-profile/
Email charles@uber.com if interested!
Contact: ca@d3in.org http://www.d3in.org/ https://github.com/charlax