GensDeConfiance | Nantes, France | Onsite | Full Time
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).
GensDeConfiance | Nantes, France | Onsite | Full Time
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).
GensDeConfiance | Nantes, France | Onsite | Full Time
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).
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.
Let's say you're fixing a bug in this code, and you find out that the `if`
branch is not covered. You're left to wonder why. The developer did not have
enough time? They decided it was too trivial to need a test?
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("...")
### It is not feasible in an old codebase
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.
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?
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?
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?
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?
5) Rider Payments - Amsterdam, Netherlands - Mobile & backend engineers (all levels). This team lets everyone use their preferred payment method to pay for Uber rides. Email [email protected]
Charles, Python-lover, knows Django, jQuery, AppEngine, Linux; looking for a full-time position in Europe or in the US. I'm French and am living in San Francisco (and really enjoying it). I love learning and can do it extremely rapidly.
Yes, I read (or skim through) about 200 articles a day (it takes me 30'). I refine my list on a monthly basis and make sure only relevant RSS feed are listed to make sure I am not overwhelmed.