Aiming for 100% code coverage is something I'd really love to do. But I don't have the time to write all the tests I want. Do you really have the time to do it?
It's different while working with TDD approach. Then high coverage is actually something that comes out naturally, as tests also serves as requirements. But this is not everyone's cup of tea, and "forcing" people to use this methodology for the sake of coverage is just bad.
In my opinion, writing tests should start with edge cases. Writing simple cases is nice and will up your coverage, but – it will be tested manually, it probably have been tested by you and – given things around work – should work, if there is no logical errors. But edge cases – missing properties, malformed values, etc. – this is the place to write tests for.
I like TDD if I'm writing pure functions with very well defined rules (recent example, pluralization rules for different languages, since many Slavic languages have similar but not identical rules).
Not as big of a fan with web apps, as I find it restrictive, and I'd rather add tests after code then (but maybe that's just because I'm bad at design :D).
There are miles and miles between knowing something and using it. For example, TDD doesn't work when you need visual regression testing (or maybe it does, but I don't know how to implement it).
I really love TDD and often find myself spending too much time writing tests for my apps and then being too tired to write the actual code :D
I mean I personally wouldn't use TDD to develop apps that are run on the web (essentially a buzzword for a website that has more functionality than an informative company or personal page, such as booking.com, a taxi booking app, etc. - anything with a lot of dynamic content).
I can use it for some functionality, but not the whole thing (in contrast to Obey the testing goat that advocates always using TDD).
Such apps, in my opinion, should consist of modules. And a lot of modules, especially the ones that are just emitting API, can be done with TDD. It's a whole different story with front-end, but even there you can try TDD with E2E tests. Because you only define "handlers", and they can be defined before the coding starts.
In my own experience, having and keeping 100% code coverage has improved my speed. My micro services/bots are consistently running with the least problems and require very little maintenance. Combined with full CI, CD and linting it is very fun to work on. I work solo mostly just due to how the team is but when they do work on it or see it they are impressed.
The confidence I have is really high, I am on a 12 day vacation and know that there is a very high chance not a single one of my services will have any issues. Note that this does combine with k8s / some orchestration tool as we do have server patching and the time.
This doesn't even take into account the speed and ease of adding new features on top of something with high test coverage. It's great, would recommend.
I never said that having high coverage is bad. All I am saying is, developing it takes a lot of time. In a perfect world, everyone would have time to write all the tests they want. But reality is different, and sometimes you just have to ship the feature.
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.
Aiming for 100% code coverage is something I'd really love to do. But I don't have the time to write all the tests I want. Do you really have the time to do it?
It's different while working with TDD approach. Then high coverage is actually something that comes out naturally, as tests also serves as requirements. But this is not everyone's cup of tea, and "forcing" people to use this methodology for the sake of coverage is just bad.
In my opinion, writing tests should start with edge cases. Writing simple cases is nice and will up your coverage, but – it will be tested manually, it probably have been tested by you and – given things around work – should work, if there is no logical errors. But edge cases – missing properties, malformed values, etc. – this is the place to write tests for.
Everyone should learn TDD, IMO.
Doesn't mean you should always use it.
I like TDD if I'm writing pure functions with very well defined rules (recent example, pluralization rules for different languages, since many Slavic languages have similar but not identical rules).
Not as big of a fan with web apps, as I find it restrictive, and I'd rather add tests after code then (but maybe that's just because I'm bad at design :D).
There are miles and miles between knowing something and using it. For example, TDD doesn't work when you need visual regression testing (or maybe it does, but I don't know how to implement it).
I really love TDD and often find myself spending too much time writing tests for my apps and then being too tired to write the actual code :D
What do you mean by web apps?
I mean I personally wouldn't use TDD to develop apps that are run on the web (essentially a buzzword for a website that has more functionality than an informative company or personal page, such as booking.com, a taxi booking app, etc. - anything with a lot of dynamic content).
I can use it for some functionality, but not the whole thing (in contrast to Obey the testing goat that advocates always using TDD).
Such apps, in my opinion, should consist of modules. And a lot of modules, especially the ones that are just emitting API, can be done with TDD. It's a whole different story with front-end, but even there you can try TDD with E2E tests. Because you only define "handlers", and they can be defined before the coding starts.
In my own experience, having and keeping 100% code coverage has improved my speed. My micro services/bots are consistently running with the least problems and require very little maintenance. Combined with full CI, CD and linting it is very fun to work on. I work solo mostly just due to how the team is but when they do work on it or see it they are impressed.
The confidence I have is really high, I am on a 12 day vacation and know that there is a very high chance not a single one of my services will have any issues. Note that this does combine with k8s / some orchestration tool as we do have server patching and the time.
This doesn't even take into account the speed and ease of adding new features on top of something with high test coverage. It's great, would recommend.
Hey miniscruff!
I never said that having high coverage is bad. All I am saying is, developing it takes a lot of time. In a perfect world, everyone would have time to write all the tests they want. But reality is different, and sometimes you just have to ship the feature.
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.