6 ms·

The problem I have with Clean Code and other design philosophies is there are so test driven. TDD adherants will tell you that lots of unit tests will make the

by zz865 5y ago

The problem I have with Clean Code and other design philosophies is there are so test driven. TDD adherants will tell you that lots of unit tests will make the code clearer, but I'm not convinced. All the hoops people have to jump through with dependency injection, test code overhead I'm not convinced any more that all this clean code is better than the stuff we wrote 20 years ago that was just tested at the final product level.

skybrian 5y ago
Whether and how to use mocks is a different decision than how much to test. There are people who write a lot of tests and also dislike mocks.
nowherebeen 5y ago
I kind of agree on some level. The amount of work required doesn't necessarily justify the benefits. Especially for non-critical features.
mike_d 5y ago
I write concise procedural PHP with 0% test coverage for all my personal projects. They handle easily 2-3x the traffic of $dayjob and don't fall over on a regular basis. We need to go back to writing code like we are on resource constrained systems, which forced you to be explicit in what you did and think about why you were doing it.
barbazoo 5y ago
I've grown to rely much more heavily on integration level testing for that exact reason. One still has to mock certain dependencies such as 3rd party APIs but it's far more reusable to figure out how to do that imo than figuring out how to mock every single class you're interacting with.
- kqr 5y ago
  Now I'm feeling dumb but... why would you ever need to mock every single class you're interacting with? I'm often test-driving stuff with unit level tests and the only times I have to mock collaborators are when the collaborators are - third party services, - badly designed, or - not built yet. This has nothing to do with unit/integration level testing.
  - barbazoo 5y ago
    I was thinking of access to files, database, http endpoints, etc that need to be mocked if the unit your testing has dependencies that do those things. With integration tests my expectation is that we're using real dependencies just fake data which is often easier to set up.
    - kqr 5y ago
      If anywhere close to 100 % of your classes accesses files, database, http endpoints etc. I still think you have badly designed code. (And if that code had been test driven, maybe it would have had fewer classes with external dependencies.)
dktoao 5y ago
My own experience is that companies that have some sort of formal automated testing have MUCH higher quality code. A testable codebase has to be modular, people spend less time chasing bugs and can refactor more confidently. That being said there are some over-the-top testing philosophies that are more actively harmful than helpful.
- zz865 5y ago
  Sure, but do you think the formal automated testing could be integration tests and avoid unit tests altogether? Esp for microservices I think this could be the best way to go. So much simpler and confirms you're getting whats in the spec.
  - dktoao 5y ago
    I think they could be any kind of test that makes sense, so yes. I think the important bit is the automated part.
  - Faint 5y ago
    Integration tests can become heavy for complex systems, and unit testing then gives you faster test-modify loop when developing code.
  - mnsc 5y ago
    I think that "good coverage" with integration tests certainly is possible. But to get that coverage /confidence you typically will have to make other test enabling code that while not being DI and stuff that affects the production code still is code. I was at a place where it was practical to drive most of the testing this way and we had to produce fragile and complicated code to set up the database in the proper way. And of course the tests were too slow so we made lots of effort to optimize. And in the end the coverage was too low but we had enough confidence to release often. That confidence was partly due to our customers being so deep in our product without a proper competitor so the bugs the customer found was not a big deal! :)
jjtheblunt 5y ago
mocking and dependency injection (what a stilted phrase!) seem to have be championed by "Uncle Bob" (definitely not my uncle). perhaps the pertinent take-away is "be sure you test thoroughly" rather than "do things my way and you will mess your code up egregiously, likely increasing the cognitive load to work with it beyond sensibility, and maybe test thoroughly as a side-effect thereof".
spywaregorilla 5y ago
Yes, I hate the mentality that unit tests are the holy grail. I work in data science. A lot of data scientists are very mediocre programmers. The solution was for software engineers to assert that data scientists at our org should work more like them. Test coverage is pushed as a critical metric. But it's really a terrible fit for what we're doing. Data science QA needs to track the state of the data at different steps in the pipeline. Unit tests, imo, are better suited to uses cases that deal with user input where you can concretely cover a good spectrum of expected states. Not all unit tests are bad of course, but many in my context, imo, are unhelpful.
cjfd 5y ago
Perhaps when you just release something once for once customer and never look at the code again. If you actually want to maintain something and release it multiple times this is very untrue. Let us say that a feature takes twice as long to implement the TDD way. So without tests it takes N and with tests it takes 2N. Sounds like a clear win for omitting the tests, right? No, very wrong.... How do you even know any of your previous features still work? Testing? Hmm.... not automatically if I get the gist of what you are saying... Manually? O dear.... Hmm.... You do realize that it is very easy for code to have unintented consequences, right? So, ideally, with every release any feature could be broken. You have to test them all N.... manually... If there are m releases this would be m N. If m is some percentage of N. E.g, on average you release every 10 features, we see that development time suddenly becomes of the order of N^2. Ow.... the TDD development time is still order N..... Could it perhaps be that this statement is actually incredibly short sighted.... Then there is the code quality issue. The stuff that was written 20 years ago was somewhat hard to refactor because noone dared because who knows what would break. So basically every code base would degrade into a mess and become harder and harder to maintain over time. A code base that is maintained with automated tests can be improved as time goes on with relatively low risk.
handsaway 5y ago
In my experience, TDD adherents tend to work in languages with no type systems (JS, Ruby, Python) or languages with types of insufficient expressivity to enforce invariants in the code without significant effort (Java). Unit tests are ultimately failings of your type system, a sufficiently advanced type system with dependent types would make them entirely redundant IMO. Integration tests are still useful as a compiler can hardly be expected to check the validity of cross-application-boundary concerns (unless?). That said, I think TDD is a cargo cult. I think a better approach is to determine on a case-by-case basis if a test is useful for whatever you're working on and developing a sense for that is part of becoming a better software developer. Things like coverage metrics completely obliterate this nuance and lead to some of the most obvious, ridiculous tests I've ever seen.
- kqr 5y ago
  > I think a better approach is to determine on a case-by-case basis if a test is useful for whatever you're working on and developing a sense for that is part of becoming a better software developer. Do you have any hard evidence that this is actually a skill that some people have and others don't? How do you even measure it to verify? I'm genuinely curious -- I've been thinking in these terms myself recently, too, but my literature search came up empty.

by zz865 5y ago

skybrian 5y ago

Whether and how to use mocks is a different decision than how much to test. There are people who write a lot of tests and also dislike mocks.

nowherebeen 5y ago

I kind of agree on some level. The amount of work required doesn't necessarily justify the benefits. Especially for non-critical features.

mike_d 5y ago

I write concise procedural PHP with 0% test coverage for all my personal projects. They handle easily 2-3x the traffic of $dayjob and don't fall over on a regular basis. We need to go back to writing code like we are on resource constrained systems, which forced you to be explicit in what you did and think about why you were doing it.

barbazoo 5y ago

I've grown to rely much more heavily on integration level testing for that exact reason. One still has to mock certain dependencies such as 3rd party APIs but it's far more reusable to figure out how to do that imo than figuring out how to mock every single class you're interacting with.

kqr 5y ago
Now I'm feeling dumb but... why would you ever need to mock every single class you're interacting with? I'm often test-driving stuff with unit level tests and the only times I have to mock collaborators are when the collaborators are - third party services, - badly designed, or - not built yet. This has nothing to do with unit/integration level testing.
- barbazoo 5y ago
  I was thinking of access to files, database, http endpoints, etc that need to be mocked if the unit your testing has dependencies that do those things. With integration tests my expectation is that we're using real dependencies just fake data which is often easier to set up.
  - kqr 5y ago
    If anywhere close to 100 % of your classes accesses files, database, http endpoints etc. I still think you have badly designed code. (And if that code had been test driven, maybe it would have had fewer classes with external dependencies.)

dktoao 5y ago

My own experience is that companies that have some sort of formal automated testing have MUCH higher quality code. A testable codebase has to be modular, people spend less time chasing bugs and can refactor more confidently. That being said there are some over-the-top testing philosophies that are more actively harmful than helpful.

zz865 5y ago
Sure, but do you think the formal automated testing could be integration tests and avoid unit tests altogether? Esp for microservices I think this could be the best way to go. So much simpler and confirms you're getting whats in the spec.
- dktoao 5y ago
  I think they could be any kind of test that makes sense, so yes. I think the important bit is the automated part.
- Faint 5y ago
  Integration tests can become heavy for complex systems, and unit testing then gives you faster test-modify loop when developing code.
- mnsc 5y ago
  I think that "good coverage" with integration tests certainly is possible. But to get that coverage /confidence you typically will have to make other test enabling code that while not being DI and stuff that affects the production code still is code. I was at a place where it was practical to drive most of the testing this way and we had to produce fragile and complicated code to set up the database in the proper way. And of course the tests were too slow so we made lots of effort to optimize. And in the end the coverage was too low but we had enough confidence to release often. That confidence was partly due to our customers being so deep in our product without a proper competitor so the bugs the customer found was not a big deal! :)

jjtheblunt 5y ago

mocking and dependency injection (what a stilted phrase!) seem to have be championed by "Uncle Bob" (definitely not my uncle). perhaps the pertinent take-away is "be sure you test thoroughly" rather than "do things my way and you will mess your code up egregiously, likely increasing the cognitive load to work with it beyond sensibility, and maybe test thoroughly as a side-effect thereof".

spywaregorilla 5y ago

Yes, I hate the mentality that unit tests are the holy grail. I work in data science. A lot of data scientists are very mediocre programmers. The solution was for software engineers to assert that data scientists at our org should work more like them. Test coverage is pushed as a critical metric. But it's really a terrible fit for what we're doing. Data science QA needs to track the state of the data at different steps in the pipeline. Unit tests, imo, are better suited to uses cases that deal with user input where you can concretely cover a good spectrum of expected states. Not all unit tests are bad of course, but many in my context, imo, are unhelpful.

cjfd 5y ago

Perhaps when you just release something once for once customer and never look at the code again. If you actually want to maintain something and release it multiple times this is very untrue. Let us say that a feature takes twice as long to implement the TDD way. So without tests it takes N and with tests it takes 2N. Sounds like a clear win for omitting the tests, right? No, very wrong.... How do you even know any of your previous features still work? Testing? Hmm.... not automatically if I get the gist of what you are saying... Manually? O dear.... Hmm.... You do realize that it is very easy for code to have unintented consequences, right? So, ideally, with every release any feature could be broken. You have to test them all N.... manually... If there are m releases this would be m N. If m is some percentage of N. E.g, on average you release every 10 features, we see that development time suddenly becomes of the order of N^2. Ow.... the TDD development time is still order N..... Could it perhaps be that this statement is actually incredibly short sighted.... Then there is the code quality issue. The stuff that was written 20 years ago was somewhat hard to refactor because noone dared because who knows what would break. So basically every code base would degrade into a mess and become harder and harder to maintain over time. A code base that is maintained with automated tests can be improved as time goes on with relatively low risk.

handsaway 5y ago

In my experience, TDD adherents tend to work in languages with no type systems (JS, Ruby, Python) or languages with types of insufficient expressivity to enforce invariants in the code without significant effort (Java). Unit tests are ultimately failings of your type system, a sufficiently advanced type system with dependent types would make them entirely redundant IMO. Integration tests are still useful as a compiler can hardly be expected to check the validity of cross-application-boundary concerns (unless?). That said, I think TDD is a cargo cult. I think a better approach is to determine on a case-by-case basis if a test is useful for whatever you're working on and developing a sense for that is part of becoming a better software developer. Things like coverage metrics completely obliterate this nuance and lead to some of the most obvious, ridiculous tests I've ever seen.

kqr 5y ago
> I think a better approach is to determine on a case-by-case basis if a test is useful for whatever you're working on and developing a sense for that is part of becoming a better software developer. Do you have any hard evidence that this is actually a skill that some people have and others don't? How do you even measure it to verify? I'm genuinely curious -- I've been thinking in these terms myself recently, too, but my literature search came up empty.