My colleague: I don't want to increase test coverage, we still have bugs.

Dude we have bugs because we don't have tests...

  • 0
    I told this dude his approach wasn't the best when he did the first of our main view. When I had to add something to our second main view, we had specific requirements that couldn't be filled with his approach. So we agreed to go with mine. Now, the requirements came for the first view (that turned into a huge god class). But I should leave it like that because "we have bugs" (even though I've been keeping on working until like 8 for the last two weeks trying to fix this).

    No shit we have bugs our codebase is a fucking mess. So I've been ordered to just keep adding quickfixes, with like zero respect for the fact it's getting less and less pleasurable to work like that.

    About 20 months into my first job, and it was ok when we were in office. We had actual processes. Since the lockdown, it turned into a shitshow, and I don't feel like I'm learning anything there anymore.
  • 2
    In fairness, I'm not necessarily for increasing test coverage just for the sake of it. In my experience that gets people to pointlessly cover boilerplate code to push the number up, while ignoring the parts that actually need thorough testing.

    What I'm very strict on though is TDD for *bugs* (not necessarily for all development, but for this it's crucial IMHO.) If you're fixing a bug, I want to see one or more test cases that all fail *before* the bug is fixed, and then pass afterwards. If you've got loads of bugs and you start taking that approach to development, you'll generally find your coverage of the *relevant* parts of the code increases quite rapidly.
  • 0
    We simply do not have tests for the moment. We had to write a whole product in 8 months and we couldn't keep up with the pace so we simply do not have any tests.
  • 0
    I mean I don't really like the framework we're using, my ideas are constantly pushed back by the senior, who then proceed one month later to claim his own version of it. On the other hands I'm now in the UK and have contracts proposition all over my inbox. I should really think of moving on before I snap and tell them truth bombs. I might need a reference.

    With a little luck I'll get fired before Christmas though, Wall Street's hungry. They did that last year. "Economical downsizing".
  • 2
    It would say go for integration tests if you do not have any tests. Probably the best time investment if you unfortunately have to choose.
  • 0
    1. add tests
    2. backlog features to hold deadline
    3. ???
    4. profit due to a working product with reduced functionality instead of a bug infested pile of garbage
  • 2
    @ostream Skipping tests to meet a deadline is *always* a false economy. You'll find bugs that could have been prevented with proper tests, and fixing those will always take longer than if you'd had written decent tests in the first place.

    If someone comes to me with a project like that, I run.
Add Comment