The article sounds very much like the author is writing tests after, so writing tests for the code already written.
I had very similar experience when writing tests after.
And it turned around completely when I started writing tests first.
Now the tests are not aiming at specific properties of the code, nor are they duplicating the thought patterns in the code. They are simply examples of what the code should do, and as such are documentation and formal/informal specification. Formal in that code is a formal system, informal in that they aren't actually trying to be a complete specification.
So if you're suffering the same symptoms as the author, I suggest you try test first, it's a world of difference.
(And of course all the comments about safety for refactoring, programming over time etc.)
I had very similar experience when writing tests after.
And it turned around completely when I started writing tests first.
Now the tests are not aiming at specific properties of the code, nor are they duplicating the thought patterns in the code. They are simply examples of what the code should do, and as such are documentation and formal/informal specification. Formal in that code is a formal system, informal in that they aren't actually trying to be a complete specification.
So if you're suffering the same symptoms as the author, I suggest you try test first, it's a world of difference.
(And of course all the comments about safety for refactoring, programming over time etc.)