Git is a pox on developers. There's nothing Git can do that you can't accomplish with make + emacs. I have stopped taking jobs that require me to use a VCS, and I have been happier and more productive.
Next on the chopping block: the cult of useless unit tests!
This comment is suffering from an extreme case of Poe's law; was this sarcasm or not?
[edit]
If it is sarcasm, I should point out that the copyright on the AWK scripts linked predate subversion so for "burdensome to manage VCS" think more CVS and less git.
I've never seen anyone argue strongly against git (or VCS more generally) like GP, but I have definitely seen people earnestly arguing against testing (unit and otherwise, though most only argue against unit testing). It has led to some baffling conversations, especially the person who wanted to eliminate all tests but didn't want to replace the V&V effort with something else (that is, they just wanted to code and be done with it, let the users test it).
I am one of the world's biggest proponents of automated testing, but I find the obsession with unit testing to be weird.
You usually get much more bang for your buck with integration and e2e tests than unit tests. Tests have the most power when it is significantly harder to write a correct implementation than it is to write a correct test. As a system grows it becomes harder to reason about its correctness, so testing at the smallest level seems backwards.
On top of that, unless you are exporting a public API, most units are free to change, so you really only care that the software as integrated in your program is correct. In my experience, the overwhelming majority (as in well over 99%) of unit tests are changed because the unit's expected behavior is changed before they ever detect a bug.
There are some things that would be units for which it's easier to write a test than a correct implementation. Besides the obvious examples (e.g. it's easier to test if something is sorted than to sort something), if you have code that must be hand-optimized for performance reasons, then you can run a battle-tested suboptimal version and compare the outputs to get a unit test for free.
I think we're in agreement, mostly. One of the perennial debates is what is a unit? Is it a class, a module, a compilation unit, a library, a function? If it's a function, do we need to test every function? What about functions that only get used by our public interface but aren't our public interface? Sometimes it makes sense to test them, but often not. In the end I only write unit tests against the exported methods/functions of a class or module and consider the unit to be the class or module and its public interface, anything below that may get a test if its sufficiently complex, but often not because there's no need (it's exercised by the tests I'm already writing, or it's dead code).
The point isn't to say VCS is pointless, just that some use-cases (in this case a website) doesn't always fit well into a commit-oriented workflow, where I prepare a changeset, create a commit then push it.
6 comments
[ 0.16 ms ] story [ 29.0 ms ] threadNext on the chopping block: the cult of useless unit tests!
[edit]
If it is sarcasm, I should point out that the copyright on the AWK scripts linked predate subversion so for "burdensome to manage VCS" think more CVS and less git.
You usually get much more bang for your buck with integration and e2e tests than unit tests. Tests have the most power when it is significantly harder to write a correct implementation than it is to write a correct test. As a system grows it becomes harder to reason about its correctness, so testing at the smallest level seems backwards.
On top of that, unless you are exporting a public API, most units are free to change, so you really only care that the software as integrated in your program is correct. In my experience, the overwhelming majority (as in well over 99%) of unit tests are changed because the unit's expected behavior is changed before they ever detect a bug.
There are some things that would be units for which it's easier to write a test than a correct implementation. Besides the obvious examples (e.g. it's easier to test if something is sorted than to sort something), if you have code that must be hand-optimized for performance reasons, then you can run a battle-tested suboptimal version and compare the outputs to get a unit test for free.