5 ms·

I have an idea and I know how to get started. Not doing end-to-end because I also do unit tests and they improve my API. It's just that they're not perfect, esp

I have an idea and I know how to get started. Not doing end-to-end because I also do unit tests and they improve my API. It's just that they're not perfect, especially duration-wise. My point is that I don't want get discouraged by being confused about best practices. Most of the software suffers from any testing, and many juniors read articles like these. Seniors do YOLO, correctly or their own way. Bit offtop, not debunking the content of this post though!

yojo 4y ago
I have personally worked on a team where velocity collapsed under the weight of the test suite. There were lots of brittle mocks. I think we even did mock out the Ruby equivalent of the HTTP client. Every change would inevitably break tests (not functionality!) and developers were spending more than half their time wrestling with the test suite. All of us could have used this article. Please always strive to improve your practice. Commit things that aren’t perfect, but try to internalize best practices over time. Gradually raise your own code quality bar as you get better. Learning from posts like the OP is super important if you don’t have a good senior Eng on your team. A group of smart juniors can easily code themselves into a hole of left to their own devices. I know this, because I did this.
- pydry 4y ago
  >Every change would inevitably break tests (not functionality!) and developers were spending more than half their time wrestling with the test suite. I find that this invariably happens because the team tries to test implementation at a very low level rather than behavior at a high level. I blame an overemphasis on unit tests over integration testing (e.g. J B Rainsberger's inane rant) and tutorials that imply that, for example, if you build a class you have to have some tests for that class.
  - icedchai 4y ago
    At a previous company, someone established a "rule" that every "new function or method" needed its own test. Unless you lucked out with a lax reviewer (like me!) , your code would not pass review if this wasn't followed. Meanwhile, there were basically zero integration or e2e tests. People spent more time adding and maintaining useless tests...
- the_gipsy 4y ago
  These sound like checksum tests. If you touch anything, they fail. That's all they do now, alert you that yes, you touched that code, now go figure the new checksum for the next poor soul.
- hynek 4y ago
  FWIW I’m a former senior-less junior that programmed himself into a hole. My blog and conference talks are exactly the material that I’d loved to have had ~10 years ago. Not sure if I’d have been smart enough to take my advice though. ;)
iratewizard 4y ago
Agreed. One thing Juniors don't get (and some seniors) is when to test. I see them writing tests on business logic and have to correct them regularly. I've had to sit down and explain to 3rd party technical resources that they're foolishly asking for more technical debt by asking for certain tests. The other thing Juniors don't get is prototyping. I regularly build something quickly to get the problem set into my head. If it's good enough, I'll leave it. If it's got issues, I'll throw it away and start fresh now that I know what I'm solving. Juniors don't work fast enough or effective enough to do things like that without putting timelines at risk. Plus, they frequently want to do some cargo cult methodology of the week like TDD.
- nescioquid 4y ago
  > I see them writing tests on business logic and have to correct them regularly. Are you saying you have to tell the developers not to test business logic, or that you have to fix the tests they write?
  - iratewizard 4y ago
    The former. Business logic changes regularly. New phases of projects frequently require changes that break the unnecessary business logic test code. Test code should fail when an important underlying mechanism regresses. If it always fails on the next phase of the project because some hapless idiot needed to cover every line, the signal to noise ratio gets weaker and the purpose of the test code is lost.
    - nescioquid 4y ago
      Thanks for the clarification -- that's what I suspected, but thought I must be misreading or misunderstanding, but I also don't know your situation and trust you're making the right set of trade-offs here. If your system is today a cuttlefish, yesterday a cow, and tomorrow a crab, cow tests don't do you much good. That sounds like a crazy environment, and I'd maybe have a care that those hapless idiots are sane people in an insane place.

yojo 4y ago

I have personally worked on a team where velocity collapsed under the weight of the test suite. There were lots of brittle mocks. I think we even did mock out the Ruby equivalent of the HTTP client. Every change would inevitably break tests (not functionality!) and developers were spending more than half their time wrestling with the test suite. All of us could have used this article. Please always strive to improve your practice. Commit things that aren’t perfect, but try to internalize best practices over time. Gradually raise your own code quality bar as you get better. Learning from posts like the OP is super important if you don’t have a good senior Eng on your team. A group of smart juniors can easily code themselves into a hole of left to their own devices. I know this, because I did this.

pydry 4y ago
>Every change would inevitably break tests (not functionality!) and developers were spending more than half their time wrestling with the test suite. I find that this invariably happens because the team tries to test implementation at a very low level rather than behavior at a high level. I blame an overemphasis on unit tests over integration testing (e.g. J B Rainsberger's inane rant) and tutorials that imply that, for example, if you build a class you have to have some tests for that class.
- icedchai 4y ago
  At a previous company, someone established a "rule" that every "new function or method" needed its own test. Unless you lucked out with a lax reviewer (like me!) , your code would not pass review if this wasn't followed. Meanwhile, there were basically zero integration or e2e tests. People spent more time adding and maintaining useless tests...
the_gipsy 4y ago
These sound like checksum tests. If you touch anything, they fail. That's all they do now, alert you that yes, you touched that code, now go figure the new checksum for the next poor soul.
hynek 4y ago
FWIW I’m a former senior-less junior that programmed himself into a hole. My blog and conference talks are exactly the material that I’d loved to have had ~10 years ago. Not sure if I’d have been smart enough to take my advice though. ;)

iratewizard 4y ago

Agreed. One thing Juniors don't get (and some seniors) is when to test. I see them writing tests on business logic and have to correct them regularly. I've had to sit down and explain to 3rd party technical resources that they're foolishly asking for more technical debt by asking for certain tests. The other thing Juniors don't get is prototyping. I regularly build something quickly to get the problem set into my head. If it's good enough, I'll leave it. If it's got issues, I'll throw it away and start fresh now that I know what I'm solving. Juniors don't work fast enough or effective enough to do things like that without putting timelines at risk. Plus, they frequently want to do some cargo cult methodology of the week like TDD.

nescioquid 4y ago
> I see them writing tests on business logic and have to correct them regularly. Are you saying you have to tell the developers not to test business logic, or that you have to fix the tests they write?
- iratewizard 4y ago
  The former. Business logic changes regularly. New phases of projects frequently require changes that break the unnecessary business logic test code. Test code should fail when an important underlying mechanism regresses. If it always fails on the next phase of the project because some hapless idiot needed to cover every line, the signal to noise ratio gets weaker and the purpose of the test code is lost.
  - nescioquid 4y ago
    Thanks for the clarification -- that's what I suspected, but thought I must be misreading or misunderstanding, but I also don't know your situation and trust you're making the right set of trade-offs here. If your system is today a cuttlefish, yesterday a cow, and tomorrow a crab, cow tests don't do you much good. That sounds like a crazy environment, and I'd maybe have a care that those hapless idiots are sane people in an insane place.