3 ms·

If you don't have time to write good tests, maybe consider not writing any tests. I've worked for many a startup where we didn't have any tests because we rewr

If you don't have time to write good tests, maybe consider not writing any tests. I've worked for many a startup where we didn't have any tests because we rewrote everything every few months. And that was ok because everyone was happy to have a lot of shit written fast. I guess maybe what I'm trying to say is that shitty tests are sometimes worse than no tests.

JohnBooty 3y ago
I don't agree that private method tests are shitty. However, I do agree that maybe there is a time during which it's OK to just not have tests. If you are just spitballing it, prototyping, code jamming, maybe even blasting out an MVP for alpha or beta testers. Sure. Part of mastering a craft is making reasoned decisions about breaking rules.
- sverhagen 3y ago
  I can see a process of triaging and deciding that some code isn't worth testing (yet), but the broader idea of "this is just a prototype", I'd like to push back on, unless you work in the rare place where they actually start over after the prototype. "Blasting out an MVP," you say? That should be production code then, with production-grade testing. I too work for a startup, and well-tested code allows us to release often and with confidence. I am humbled every day by unit tests slapping my wrist when I attempt something stupid.
  - josephg 3y ago
    > unless you work in the rare place where they actually start over after the prototype. Every line of code will last some amount of time. Some lines will be maintained in production for decades. And others will be thrown out in a few weeks. For example, if I’m mocking up a UI, the css I write won’t outlast the mock-up. Or doing a game jam. Or prototyping a different way to structure some code. Unit tests are useful for long lived code but they slow down your capacity to do scrappy iterations. Whether you need to prioritise short term velocity or long term reliability depends on the needs of the project you’re working on.
    - sverhagen 3y ago
      Code just tends to live longer than developers often anticipate. They put more trust in their organizations than is warranted about how much time they will be given later to go back and clean things up. (This probably happens because the original work is over-estimated and then the project is delivered under in a crunch, instead of having some breathing time to clean things up.) But again, this is all situational, you may work in different circumstances than I ever have.

JohnBooty 3y ago

I don't agree that private method tests are shitty. However, I do agree that maybe there is a time during which it's OK to just not have tests. If you are just spitballing it, prototyping, code jamming, maybe even blasting out an MVP for alpha or beta testers. Sure. Part of mastering a craft is making reasoned decisions about breaking rules.

sverhagen 3y ago
I can see a process of triaging and deciding that some code isn't worth testing (yet), but the broader idea of "this is just a prototype", I'd like to push back on, unless you work in the rare place where they actually start over after the prototype. "Blasting out an MVP," you say? That should be production code then, with production-grade testing. I too work for a startup, and well-tested code allows us to release often and with confidence. I am humbled every day by unit tests slapping my wrist when I attempt something stupid.
- josephg 3y ago
  > unless you work in the rare place where they actually start over after the prototype. Every line of code will last some amount of time. Some lines will be maintained in production for decades. And others will be thrown out in a few weeks. For example, if I’m mocking up a UI, the css I write won’t outlast the mock-up. Or doing a game jam. Or prototyping a different way to structure some code. Unit tests are useful for long lived code but they slow down your capacity to do scrappy iterations. Whether you need to prioritise short term velocity or long term reliability depends on the needs of the project you’re working on.
  - sverhagen 3y ago
    Code just tends to live longer than developers often anticipate. They put more trust in their organizations than is warranted about how much time they will be given later to go back and clean things up. (This probably happens because the original work is over-estimated and then the project is delivered under in a crunch, instead of having some breathing time to clean things up.) But again, this is all situational, you may work in different circumstances than I ever have.