4 ms·

people ... don’t want to change how they write code. They just want tests for it Have you considered the possibility that those people are right? That's a rea

people ... don’t want to change how they write code. They just want tests for it Have you considered the possibility that those people are right? That's a reasonable conclusion to make if you are seeing lots of otherwise smart people that share an opinion that disagrees with yours. There are lots of valid reasons to change the style in which you write code. In my mind, fitting somebody's fad testing scheme is not one of them. Here's a second opinion from a guy who also likes tests, but doesn't think it's a good idea to structure your whole codebase just to accommodate them: http://david.heinemeierhansson.com/2014/test-induced-design-damage.html http://david.heinemeierhansson.com/2014/test-induced-design-...

TeMPOraL 9y ago
I strongly agree with that, too. My current, experience-born belief is that if the only reason for introducing some architectural pattern is to accommodate testing better, the change is wrong and will likely hurt the code quality. Yes, you need to concede a little bit to allow for test points, but turning your code inside-out to have it go through three layers of indirection so that the middle one can be mocked easily? That's just stupid.
- afarrell 9y ago
  yea, you should be changing code style to increase modularity in a way that is conceptually coherent in terms of what is easy to hold in your head. Increased testability should fall out of that because you can think through "What invariant should hold true about X under conditions/inputs Y1...Y4?"
  - hinkley 9y ago
    Code you can hold in your head usually has a smaller surface area. Fewer moving parts equals easier testing.
hacker_9 9y ago
Usually splitting out into interfaces is done in static languages as that's the best type-safe way to do things. It's not a fad, it's been like that since the beginning.
- kelnos 9y ago
  There is absolutely no reason (except to fit into a particular pattern of testing) to turn everything into an interface[1]. That has nothing to do with type safety. [1] Obviously some things do make sense to put behind interfaces, but I find that most Java developers go interface crazy and the code ends up being an unreadable mess.
profalseidol 9y ago
The main problem is "obsession" as pointed out by that blog post you linked. Obsession of "one size fits all" or "silver bullet". I believe the authors of agile manifesto wrote this disclaimer. If it doesn't make sense to make unit tests to MVC controllers, then don't. In my experience, management looking at code coverage not being 100% is one reason (although bad) that this "unit test everything" happened. I tried shouting this out, but team lead didn't have the ability to learn from a junior and use Sonar's configuration.
hinkley 9y ago
Have you considered the possibility that those people are right? Every time I’m looking at a code review with awful tests. I started out in statically typed languages and I can’t shake the feeling that we need to tool our way out of the testing conundrum. Anything that is this hard to get right shouldn’t be the equal responsibility of every team member. For every other problem of this magnitude we have people who specialize and everyone else just has to be aware of the issues and consult when in doubt. So it’s a struggle for me to try to get people do adhere to the strategy we’ve accepted without believing it’s the end all be all of software robustness. Because I’m not convinced. Nothing I’ve ever mastered in software has taken me half as long as testing, and that just ain’t right. That said, I still like the structure about 80% of my tested code has. It usually does exactly what it says and nothing else. Local reasoning is a big deal to me.

TeMPOraL 9y ago

I strongly agree with that, too. My current, experience-born belief is that if the only reason for introducing some architectural pattern is to accommodate testing better, the change is wrong and will likely hurt the code quality. Yes, you need to concede a little bit to allow for test points, but turning your code inside-out to have it go through three layers of indirection so that the middle one can be mocked easily? That's just stupid.

afarrell 9y ago
yea, you should be changing code style to increase modularity in a way that is conceptually coherent in terms of what is easy to hold in your head. Increased testability should fall out of that because you can think through "What invariant should hold true about X under conditions/inputs Y1...Y4?"
- hinkley 9y ago
  Code you can hold in your head usually has a smaller surface area. Fewer moving parts equals easier testing.

hacker_9 9y ago

Usually splitting out into interfaces is done in static languages as that's the best type-safe way to do things. It's not a fad, it's been like that since the beginning.

kelnos 9y ago
There is absolutely no reason (except to fit into a particular pattern of testing) to turn everything into an interface[1]. That has nothing to do with type safety. [1] Obviously some things do make sense to put behind interfaces, but I find that most Java developers go interface crazy and the code ends up being an unreadable mess.

profalseidol 9y ago

The main problem is "obsession" as pointed out by that blog post you linked. Obsession of "one size fits all" or "silver bullet". I believe the authors of agile manifesto wrote this disclaimer. If it doesn't make sense to make unit tests to MVC controllers, then don't. In my experience, management looking at code coverage not being 100% is one reason (although bad) that this "unit test everything" happened. I tried shouting this out, but team lead didn't have the ability to learn from a junior and use Sonar's configuration.

hinkley 9y ago

Have you considered the possibility that those people are right? Every time I’m looking at a code review with awful tests. I started out in statically typed languages and I can’t shake the feeling that we need to tool our way out of the testing conundrum. Anything that is this hard to get right shouldn’t be the equal responsibility of every team member. For every other problem of this magnitude we have people who specialize and everyone else just has to be aware of the issues and consult when in doubt. So it’s a struggle for me to try to get people do adhere to the strategy we’ve accepted without believing it’s the end all be all of software robustness. Because I’m not convinced. Nothing I’ve ever mastered in software has taken me half as long as testing, and that just ain’t right. That said, I still like the structure about 80% of my tested code has. It usually does exactly what it says and nothing else. Local reasoning is a big deal to me.