Sure, in these cases I make sure to communicate before and after the feature is developed that it has no automated test suite. If my PO/boss is pushing for a faster release they hold responsibility for the outcome.
Technical debt is a big concern of mine and I'm not going to add to it without permission. Over time most people will give time for testing if you can prevent bad releases. Especially bosses that are ex developers.
Speaking as both developer and manager here. It's never an easy decision to make a technical debt, but sometimes it is the best one, others being either grind overtime to the physical limits or miss the deadline that was announced publicly.
Sometimes shipping slightly broken software is better than missing the shipment at all.
Giving time to write tests is obvious for most, and for business people we just say "development will take X days" while we know that X = development + tests. But like I've said earlier, you don't always have enough time to cover every single corner case.
To mitigate technical debt, I try to introduce (I did it before, now I am trying this in a new organization) technical sprints, for exemple every third sprint is purely technical and maintenance-based. This is the time for making a 100% coverage and refactors.
I have heard of the technical sprint before but never been apart of any. I am always skeptical of putting engineering time aside until later as, and this may just be my experience, that "free" time is the first to go when deadlines, requests or issues arise.
I mean, 100% for it if it's consistent, but whenever I try and get that stuff going like 75% of the time it's cut short or entirely.
Still, I agree that there are always conditions that fall outside an "ideal situation" and I have many times forgone tests to ship something.
I generally advocate for the best-case scenario that way when there is push back from management or other devs I have some wiggle room. But if I ( at least for me ) push for general "let's test a lot but not 100%" ideas that get pushed back until it just becomes "testing is good but whatever you want to do is fine by us".
That is if I say 100% is the minimum with linting, edge cases, and e2e tests. That will get negotiated to around 80% + linting. But if I were to push for 80% + linting, we may end up agreeing on 50% only without linting.
tl;dr I agree with everything you say, I just add a little extra so that what we both agree on actually sticks with the whole team. Because on a team of 10, it doesn't matter if I do 100% with TDD if the rest of the team doesn't write any tests.
I am always skeptical of putting engineering time aside until later as, and this may just be my experience, that "free" time is the first to go when deadlines, requests or issues arise.
That's when you plan for multiple sprints ahead and, when estimating or agreeing on a deadline, you say "4 sprints" and you already know that one will be purely tech.
Well, bottom line is, tests should be written from the hardest to the easiest, not the other (obvious) way around.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sure, in these cases I make sure to communicate before and after the feature is developed that it has no automated test suite. If my PO/boss is pushing for a faster release they hold responsibility for the outcome.
Technical debt is a big concern of mine and I'm not going to add to it without permission. Over time most people will give time for testing if you can prevent bad releases. Especially bosses that are ex developers.
If not, might be time for a change lol
Speaking as both developer and manager here. It's never an easy decision to make a technical debt, but sometimes it is the best one, others being either grind overtime to the physical limits or miss the deadline that was announced publicly.
Sometimes shipping slightly broken software is better than missing the shipment at all.
Giving time to write tests is obvious for most, and for business people we just say "development will take X days" while we know that X = development + tests. But like I've said earlier, you don't always have enough time to cover every single corner case.
To mitigate technical debt, I try to introduce (I did it before, now I am trying this in a new organization) technical sprints, for exemple every third sprint is purely technical and maintenance-based. This is the time for making a 100% coverage and refactors.
I have heard of the technical sprint before but never been apart of any. I am always skeptical of putting engineering time aside until later as, and this may just be my experience, that "free" time is the first to go when deadlines, requests or issues arise.
I mean, 100% for it if it's consistent, but whenever I try and get that stuff going like 75% of the time it's cut short or entirely.
Still, I agree that there are always conditions that fall outside an "ideal situation" and I have many times forgone tests to ship something.
I generally advocate for the best-case scenario that way when there is push back from management or other devs I have some wiggle room. But if I ( at least for me ) push for general "let's test a lot but not 100%" ideas that get pushed back until it just becomes "testing is good but whatever you want to do is fine by us".
That is if I say 100% is the minimum with linting, edge cases, and e2e tests. That will get negotiated to around 80% + linting. But if I were to push for 80% + linting, we may end up agreeing on 50% only without linting.
tl;dr I agree with everything you say, I just add a little extra so that what we both agree on actually sticks with the whole team. Because on a team of 10, it doesn't matter if I do 100% with TDD if the rest of the team doesn't write any tests.
That's when you plan for multiple sprints ahead and, when estimating or agreeing on a deadline, you say "4 sprints" and you already know that one will be purely tech.
Well, bottom line is, tests should be written from the hardest to the easiest, not the other (obvious) way around.