6

I'm in a situation at work where management and even the team I'm on, does not want to create a test suite, because:
1. It takes time to get decent code coverage. Time that could be spend doing new features
2. My team doesn't like to test.

We're now in a situation where we break something every single fucking time we relase and the manager just ignore that it's now a common occurrence. It it literally just a matter of time before the entire fucking backend will shit itself over poorly maintenanced code (who has time to do refactoring anyway) and poorly tested flow.

It annoys me greatly that a developer with many years of experience fails to see and understand that just doing test by hand, screws us over so badly.

As a junior dev, i would like to know, how are your team dealing with testing?
Because we're clearly not...

Comments
  • 1
    We can't test, way to many deadlines. We ask the customer to test, 5 minutes later they say everything works and that we can put it live.
  • 4
    There were no tests when I started.
    I wrote tests for everything, and have about 95% coverage. I write tests for every feature during and after building it. I chew at anyone who commits code without tests, then make them write tests.

    I'm sick of having untested, fragile codebases.
    Never again!
  • 5
    Write tests for your stuff, then anytime you touch something existing, Write tests for it too.

    Let them build up over time rather then stop developing until it's covered.

    Once you get a decent coverage level then bring in your test suite as a pre-merge step.

    Sometimes to get the change you want, you must make the change for them.
  • 3
    Testing of critical functionality that should not change often is important. All other testing other than manual checking by dev and qa is a colossal water of time and money. I hear more obscenely stupid things said about testing every day than about any other topic. If it's vital, automate it. If it's not vital, give it a best effort sanity check and move on or else you will spend 100x more time and money automating that label alignment than eyeballing it every release for the next 1000 years would cost.
  • 1
    Same fucking position! (also a junior dev)

    It takes more time in the end not doing it right the first time.
  • 2
    It's fucking hard to see what is right. But I may tell you that mgt is aware of everything, and opening your mouth to point out the nasties will not be good for you. If you can find it within yourself to close your mouth and just do your job and look for something else, I'd advise it. I know it more than likely goes against your very grain, but it's important to realize that those in exalted positions are fucked up pieces of shit.
  • 1
    I was surprised at my new company that we're required to maintain 100% coverage on frontend and at least 80% on backend. We also do automated uats for most frontend features. It takes time to write all these tests, but it's so nice and everything works
  • 0
    Our company doesn't do automated tests because apparently it doesn't work for our product... even though we have tons of functions we could be testing and lightening up tester loads.

    So now we're surprised when the client is demanding full regression testing be done is 6 weeks and the testers want 6 months. Ayeesh.
  • 0
    We do happy path tests, meaning we make sure shit works if you call it with correct data, who knows what happens if you dont (tho theres obviously validation in code too to limit those cases)

    Except when we don't have time and deadlines are comming, then all tests are out of the question.

    Also, the only language management and your clients speak is money. Which means what you do is "Hey listen, this thing is broken again, we've been fixing it every other day. If we could at least cover some basic functionality we could build features probably twice as fast"

    Then it depends on what your position is and if the management respects your opinion. Alternatively as a junior, you should convince your senior instead, he would be able to push it higher

    PS:
    I once wrote tests for a subsystem in a project that wasn't allowed tests because it kept broking. Didn't tell anyone and it works to this day :)
Add Comment