Comments URL: https://news.ycombinator.com/item?id=46559363

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45184808

Points: 7

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=38105449

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=33758696

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=32070627

Points: 1

# Comments: 0

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 ;)

Comments URL: https://news.ycombinator.com/item?id=25942562

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=24697187

Points: 1

# Comments: 1

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.

Comments URL: https://news.ycombinator.com/item?id=20897382

Points: 23

# Comments: 49

Comments URL: https://news.ycombinator.com/item?id=20886026

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=18997322

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=17362670

Points: 5

# Comments: 1