33
evilian
101d

If you don't write test cases, you don't have the right to cry when it breaks in production.

Comments
  • 5
    I agree. But I never said that it solves everything. I said that if you don't even test your code then you are sure to face unforeseen issues in production which could have easily been avoided if you wrote tests in the first place.
  • 3
    @irene but they are very close to it!

    Units + IT w/ mocks of env / distant components [like external integrations or another module's signal responses] + fail scenarios and you are at least 98% confident it works
  • 0
    Unit tests prove something works in tested scenarios, and breaking changes don't get introduced if done correctly. They are usually very narrow in scope and only touch on minor "units" of the code base, it's very rare to fine E2E automation testing for solid scenarios.

    Assert(1==1) does not prove it works and I have seen devs do this to get their code coverage % up, this shit pisses me off and I just delete it.

    Code bases are not ALL that can go wrong in production, good luck "unit testing" server configs and auto deployments - it's usually these that break not the code base it's self due to dependency updates.
  • 1
    Structured, reliable testing is paramount.

    Continuing that thought: proper, meaningful integration testing alone has saved the day so_many_times. Naturally there can be environment issues that surface in production, but a solid suite of meaningful integration tests give you the gift of zeroing in on the core of the issue much more quickly.
  • 2
    I am a big fan of testing... personally.

    It just makes it easier to know actually have some proof that it's consistent.
  • 1
    I totally agree!

    But tell that to a boss at a small web agency :(
Your Job Suck?
Get a Better Job
Add Comment