21–30 of 85 posts
One thing I noticed is that the scripts are written to run once, and always do everything. It would be better to have a Makefile and dependencies, so that the you can run it multiple times, and only the changes are updated.
I'll see if I can push some fixes to github.
Hold on. I have an interface file "interface.d.ts" and a whole bunch of other files reference it. Whenever I make changes to any files that depend-on/reference that file I of course also make changes to that file. This means that every file in my project is coupled to that file. How is that indicative of good or bad design?
Generally if you have to change a whole bunch of related files when you change one, it's an issue with the design.
Huh. Could you also use this to flag something for a potential bug, if a historically coupled pair is not coupled in some commit?
I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
Logical coupling crops up in lots of unexpected places as well:
Partials are functions but with no clear argument signature, so they may be used sloppily with no obvious way of determining what (interface, state expectations) they are coupled to.
I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
> This is a clear indication of how TDD will slow you down. Not shown: the part where the critical production bug you introduced was caught by your test suite, thus saving you countless hours of agony, angry customers, and lost revenue.
If you change an API, you will have to change consumers of the API. Does that mean that your code is bad?
This exists even in a low level examples: if you change a c++ class, you will need to also change the corresponding header file.
Or perhaps, am I misunderstanding the concept?
I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
> This is a clear indication of how TDD will slow you down. Not shown: the part where the critical production bug you introduced was caught by your test suite, thus saving you countless hours of agony, angry customers, and lost revenue.