Eugen Kiss

Thanks for your comment. Routing is mapping a URL to a screen and reverse routing is mapping a screen to a URL.

Concretely, when you enter yourapp.com/story/1 your router will decide to render the Story component because you defined /story/:id to map to the Story component. This direction is routing. What if in another…

Just thinking out loud: What if there was a “pre-compilation” step that transformed every JSX node in a render function into a dedicated component? (Not necessarily literal.) The advantage would be very fine-grained reactivity without the need to manually extract components. I wonder what the drawbacks are and if there is a framework that takes this approach.

What’s your view on https://github.com/kentcdodds/react-testing-library? From a cursory glance react-testing-library feels, conceptually, as if already having some useful utility functions for react-test-renderer.

I believe the snippets contain some small mistakes:

• IndexPageProps should be HomePageProps
• In the MobX/MST snippets I cannot find the spot where HomePage and ConnectedHomePage are wired up

Agreed. Identify the risks and put more testing effort into high-risk cases.

Just a side thought: I remember most of the high-profile data breaches not bringing the companies down (e.g. Equifax)…

You have a very good, common sense approach to TDD and testing in general. Plus, if this approach personally helps you then more power to you! Forcing it on everybody else is something different. However, I have the impression that an attitude as yours is the exception (even when “true” TDD might be exactly what you’re doing).

Write code for unit tests helps decouple the code.

This article, for example, didn’t find improvements to coupling and cohesion metrics for TDD. TDD != unit tests but there is some similarity. ‘Unit Testing Doesn’t Affect Codebases the Way You Would Think’ finds that code with more unit tests has actually more cyclomatic…

You don’t have a choice when it comes to requirements. For testing, you have a choice between different testing methods (unit, integration, end-to-end). Unit tests ossify code the most.

You are right that the sentence preceding the TDD article is logically wrong. I have an excuse ;): I had a longer section and quote about it, then just before releasing decided to put a condensed version to the additional notes without too much thought. I will fix it.

Why do I have to present a mathematical model? Please be more specific how I misappropriate the term ‘Lean’?

Why do you assume the worst in me and accuse me to “only want misrepresent” the TDD article? For me, coupling, cohesion etc. are code quality metrics. Number of bugs would be software quality to me. To make this…