3 ms·

It's one of those things where people who really believe in it are very vocal and will shout over anyone who dares to think there are any problems. Not everyon

It's one of those things where people who really believe in it are very vocal and will shout over anyone who dares to think there are any problems. Not everyone loves them. But, as I'm a test-lover, I have to say they're pretty amazing if you can get everyone on-board and writing good tests. As for how hard they are... It depends on how the code is structured. If the code is designed to be testable, it's pretty easy to write simple tests. Integrations get a little tougher, but as long as you know what the other side should return, it's pretty easy to stub them out. Testing existing code that was not designed to be testable is a lot harder. It typically will introduce a lot of side effects and won't be properly separated. It can be tested, but IMO just isn't worth the hassle. I've found that you end up spending as much time writing tests as you would have fixing the bugs that arise... And code doesn't get used forever. Modern dev culture insists that someone call for a rewrite eventually, no matter how good the code is, unless you're working in a system that already has decades of legacy code. My advice would be to start a small project of your own (or wait until you get a new project at work that's from scratch) and write tests from the start. It'll teach you a ton about testing and help you get the system off the ground quickly and solidly. I did this for the last big server-side system I wrote and the tests helped tremendously. The bugs that QA found were generally things that I didn't consider or that they designed wrong. The tests helped me get everything working and keep it working while they changed all kinds of things. Sadly, once that project ended up in the hands of other devs, the tests slowly died and I was the only one trying to fix them. I eventually went to another project for a while and came back to find the tests basically didn't work at all, and they died completely at that point. But they did their job at the start, and were totally worth it.

iudqnolq 6y ago
I've seen a lot of people say not to design code to be testable. That instead tests should work around whatever shape the code should be in "naturally". Writing this out this seems stupid, it's been pretty influencial on how I code (for the past year or so, I'm a complete beginner).
- wccrawford 6y ago
  To me, the shape the code should be is largely the same as easily-testable code anyhow. You want functions that do small, self-contained things so that you can reason about them efficiently. That also makes them easier to test. Yes, sometimes you end up with a monstrous function because of requirements... But then, that's how you have to test it anyhow. That said, some of the more intense testing things, like dependency injection, definitely change the shape of the code into abnormal forms. So I can agree there that it's adding complexity to the code that it shouldn't, just for testing. Some projects may warrant the increased complexity to trade for stability. I don't think most do.
  - iudqnolq 6y ago
    Small functions, sure. The most common case of this I've run into is should I use dependency injection just for testing. My function creates a Frob and interacts with it. By default Frobs persist changes to a DB and sync over the network. I don't want to do that in a test. Now I need to pass a frobFactory of (FrobConfig) -> Frob to my function. Sure in theory I could use my new configurability for all sorts of things, but in practice I only end up using the alternative path in tests. When do you not end up needing something like this?
hinkley 6y ago
> I have to say they're pretty amazing if you can get everyone on-board and writing good tests This is my main complaint about code coverage metrics. I want you to be good at test writing before you write the bulk of your tests, not after. It’s hard enough to get people to write good ones, let alone go back and fix the messy ones they wrote badly (recall I said good tests are easier to replace than bad ones). If you write a bad enough test it can take longer to fix it than throw it out and start over. But since you didn’t clearly capture the constraints the first time, do you dare delete it? What aren’t you testing after?

iudqnolq 6y ago

I've seen a lot of people say not to design code to be testable. That instead tests should work around whatever shape the code should be in "naturally". Writing this out this seems stupid, it's been pretty influencial on how I code (for the past year or so, I'm a complete beginner).

wccrawford 6y ago
To me, the shape the code should be is largely the same as easily-testable code anyhow. You want functions that do small, self-contained things so that you can reason about them efficiently. That also makes them easier to test. Yes, sometimes you end up with a monstrous function because of requirements... But then, that's how you have to test it anyhow. That said, some of the more intense testing things, like dependency injection, definitely change the shape of the code into abnormal forms. So I can agree there that it's adding complexity to the code that it shouldn't, just for testing. Some projects may warrant the increased complexity to trade for stability. I don't think most do.
- iudqnolq 6y ago
  Small functions, sure. The most common case of this I've run into is should I use dependency injection just for testing. My function creates a Frob and interacts with it. By default Frobs persist changes to a DB and sync over the network. I don't want to do that in a test. Now I need to pass a frobFactory of (FrobConfig) -> Frob to my function. Sure in theory I could use my new configurability for all sorts of things, but in practice I only end up using the alternative path in tests. When do you not end up needing something like this?

hinkley 6y ago

> I have to say they're pretty amazing if you can get everyone on-board and writing good tests This is my main complaint about code coverage metrics. I want you to be good at test writing before you write the bulk of your tests, not after. It’s hard enough to get people to write good ones, let alone go back and fix the messy ones they wrote badly (recall I said good tests are easier to replace than bad ones). If you write a bad enough test it can take longer to fix it than throw it out and start over. But since you didn’t clearly capture the constraints the first time, do you dare delete it? What aren’t you testing after?