Threads for ts

  1. 4

    It’s a cute technique, though I don’t see how it solves the issue of concerns.The way that Card is implemented, it still conflates those concerns, because it needs to know those properties. The fact that you pack them in children instead of props doesn’t really change that. If you truly want to decouple them, you blindly render {children}.

    edit: You could also just conventionally model your props as {config: Record, content: Record}. I guess my point is, we’re not really, truly separating concerns here. We’re just making it more clear what is config and what is content.

    1. 1

      We’re just making it more clear what is config and what is content.

      I think this is what the author means by “separating concerns”.

      1. 1

        My point is, clarifying the difference doesn’t separate the concerns. I’m not saying its not a useful thing to do, just that it seems to be a misunderstanding of what “separation of concerns” is. The component still hard-couples its contents to its interface. If that is done via children or other props is irrelevant.

    1. 9

      Let me start by saying that I prefer a developer who tests too much than not at all. So I appreciate posts like this. That being said, I disagree with the premise of the post, and I belive the main issue is that OP ignores one crucial aspect: cost.

      Writing any code has a cost. That cost is a compound of many things.

      • time spent designing and writing it
      • the effort spent on future maintenance of the code (which, frustratingly, you don’t know at the time of writing)
      • the inevitable growth in complexity of the code base, which leads to other problems down the road
      • additional time spent on onboarding new developers

      and possibly many more things. When we write new code, we weigh these cost against the potential value, e.g. new features, security, etc. Testing code is no different. Any testing code has a value that we have to weigh against the cost of writing it. I like to frame that value as confidence. How confident am I, after having written this test, that my code is working as intended from the perspective of my users? Weighed against the cost of writing it. Using this mental model, you will find that a lot of tests are not worth writing.

      OP addresses common objections, amongst them:

      Enforcing 100% test coverage leads to bad tests

      In their answer, they kind of hit the mark in saying:

      Putting too much focus on one particular metric might lead to gaming behavior

      or put differently by Goodhart’s law:

      When a measure becomes a target, it ceases to be a good measure.

      OP further says:

      What’s sure is that it is straightforward to write bad tests.

      Unfortunately, they dismiss the notion by saying:

      I am not sure how that would lead to bad tests.

      In my experience, if you enforce any test coverage (you don’t even need 100%), developers will write bad tests. And many of thoses tests will have negative value. That is, they don’t provide enough confidence to offset their cost.

      I have experienced this first-hand. At work, we have a code base that had ~100% code coverage at one point in time. In my estimate, 95% of those tests are worthless. How do I know? You can change the code in a way that does not break the interface of functions, nor break user behaviour, and the tests will fail (they should not). At the same You can deliberately break the code in meaningful ways, and the tests will not fail (they should).

      Test coverage is one of the tools at our disposal, it is one metric, not the metric. Use it to discover meaningful places to test. Don’t kid yourself when you are reaching for 100%. When you do, you are playing a video game, you are going for a high-score. You are not meaningfully improving your code.

      1. 1

        I totally agree; the cost of tests shouldn’t be ignored.

        I imagine the article author might respond, “just put # pragma: no cover comments in all the code that isn’t worth testing”. However, I think they would end up with quite a lot of those comments, all over their code. That would be bad—comments that are not directly relevant to the functionality of surrounding code harm the readability and editability of that code. Such comments need a strong benefit elsewhere to be worth it. And as you explained, enabling a coverage metric is not a strong benefit.