4 ms·

I'm generally for testing, but I have noticed a phenomenon that happens a lot: basically, the tests start influencing the actual design (in not a good way). To

I'm generally for testing, but I have noticed a phenomenon that happens a lot: basically, the tests start influencing the actual design (in not a good way). To get the tests working, you end up having to write a lot more infrastructure and abstraction to support it. So you end up with 6 classes where one would do, because you end up needing an extra interface, and then impl, and then mocks, and dependency injection and on and on. Not to mention extra dev infrastructure like mock rest servers and so on. This seems more prevalent in languages where the type system is pretty primitive and concise code isn't as valued (ie: java). It seems like mostly a non-issue in dynamic languages like python and ruby (where honestly I think the tests are way more useful anyway) To me, the problem is that each line of code should always be treated as a cost. More code is more cost. And if you're writing 6 classes where one or two could do, you're creating a lot of extra code. And we'll just ignore the time spent writing the test and assume that it'll pay itself back in the future, I'm just talking about the extra maintenance costs of having 6 classes hanging around and the extra time it takes to run those tests every time you compile. I guess what it comes down to is not testing for dumb things. You should be writing tests against stuff you probably think could break. I'm not really big on the idea of 100% test coverage. I think once you're testing "most" of the code the cost/benefit of way more tests is mostly just in satisfying the OCD types.

lectrick 12y ago
> To get the tests working, you end up having to write a lot more infrastructure and abstraction to support it. So you end up with 6 classes where one would do, because you end up needing an extra interface, and then impl, and then mocks, and dependency injection and on and on. I have found this to be true only when having to work with code that was not written with TDD. For example, if you're writing a new Rack middleware, it will be EXTREMELY easy to TDD and unit test. The entire Rack design (while not devoid of criticism) is sort of ingeniously simple and was clearly written with TDD/unit testing in mind as a design priority. However, if you're interested in TDD'ing a Rails controller without loading your entire stack... Good luck with that. But Rails was NOT written with TDD, nor unit testing, in mind. It's evident right in the Rails lingo- a "unit test" in Rails is (was?) a test of the model code (and everything underneath). A "true" unit test doesn't test dependencies (so for example, an ACTUAL "unit test" of model code would abstract out the entire database and mock out all the CRUD operations). So I guess I could paraphrase what you're saying as, "If you have to TDD and, in the course of this particular development work, you have to work with code that was not written via TDD, you're going to have a bad time."

lectrick 12y ago

> To get the tests working, you end up having to write a lot more infrastructure and abstraction to support it. So you end up with 6 classes where one would do, because you end up needing an extra interface, and then impl, and then mocks, and dependency injection and on and on. I have found this to be true only when having to work with code that was not written with TDD. For example, if you're writing a new Rack middleware, it will be EXTREMELY easy to TDD and unit test. The entire Rack design (while not devoid of criticism) is sort of ingeniously simple and was clearly written with TDD/unit testing in mind as a design priority. However, if you're interested in TDD'ing a Rails controller without loading your entire stack... Good luck with that. But Rails was NOT written with TDD, nor unit testing, in mind. It's evident right in the Rails lingo- a "unit test" in Rails is (was?) a test of the model code (and everything underneath). A "true" unit test doesn't test dependencies (so for example, an ACTUAL "unit test" of model code would abstract out the entire database and mock out all the CRUD operations). So I guess I could paraphrase what you're saying as, "If you have to TDD and, in the course of this particular development work, you have to work with code that was not written via TDD, you're going to have a bad time."