I think there's a few things conflated here. Writing tests after the code doesn't necessarily mean they're an afterthough, or considered a separate task (e.g. via a separate ticket). Sometimes that can be the case, but the majority of the time when I've written, or seen other developers writing, tests, they're part of the task, but written after the code is at a working point.
Tests should be written as cleanly as any other code, although obviously allowing for any nuances of the test framework being used. I've often written what I thought was clean code for the non-test part, only to find it could be improved because my tests couldn't be written well. I'd suspect the same could be found if tests were written first.
I also don't believe that just because tests are written after that they've immediately written lazily, or begrudgingly, and aren't testing the happy and unhappy paths in the code. Where that does happen, I'd heavily suspect that the developer doing so is just as likely to be writing the rest of the code lazily too, not only the tests.
Finally, I think if you're in a team that would consider functioning code without tests to be ready for production, then writing tests beforehand (which would presumably be taking up the same overall amount of time) would probably have said team questioning why a task was taking so long, and likely prompt them to ask that the tests be left until the end anyway. However, that's just generally a bit of a red flag anyway, and if you're a developer who cares about testing in a team that doesn't, you need to find a better team.
I think it's also worth mentioning that a lot of testing frameworks out there do have code coverage capabilities. I wouldn't rely on only these though, as it's not too difficult to trick them into the appearance of coverage when it's not the case, and this can lead to abuse by those developers who would take the lazy route.
Writing code without having a clear functional spec of what should this code do is hard. Very hard. I need to know what I want the code to do before I jump in and write it. I found that the best way of creating this functional spec is with testing before the code.
How do you begin writing a test for anything if the functional spec of that thing isn't clear?
Personally, I find it easiest to break the business requirements into the smallest unit of work that effectively results in a complete item. Then it becomes pretty simple to break that down across the various code layers as required to ensure an approach that follows clean, SOLID principles. Tests are more easily written for such code.
I think there's a few things conflated here. Writing tests after the code doesn't necessarily mean they're an afterthough, or considered a separate task (e.g. via a separate ticket). Sometimes that can be the case, but the majority of the time when I've written, or seen other developers writing, tests, they're part of the task, but written after the code is at a working point.
Tests should be written as cleanly as any other code, although obviously allowing for any nuances of the test framework being used. I've often written what I thought was clean code for the non-test part, only to find it could be improved because my tests couldn't be written well. I'd suspect the same could be found if tests were written first.
I also don't believe that just because tests are written after that they've immediately written lazily, or begrudgingly, and aren't testing the happy and unhappy paths in the code. Where that does happen, I'd heavily suspect that the developer doing so is just as likely to be writing the rest of the code lazily too, not only the tests.
Finally, I think if you're in a team that would consider functioning code without tests to be ready for production, then writing tests beforehand (which would presumably be taking up the same overall amount of time) would probably have said team questioning why a task was taking so long, and likely prompt them to ask that the tests be left until the end anyway. However, that's just generally a bit of a red flag anyway, and if you're a developer who cares about testing in a team that doesn't, you need to find a better team.
I think it's also worth mentioning that a lot of testing frameworks out there do have code coverage capabilities. I wouldn't rely on only these though, as it's not too difficult to trick them into the appearance of coverage when it's not the case, and this can lead to abuse by those developers who would take the lazy route.
Writing code without having a clear functional spec of what should this code do is hard. Very hard. I need to know what I want the code to do before I jump in and write it. I found that the best way of creating this functional spec is with testing before the code.
How do you begin writing a test for anything if the functional spec of that thing isn't clear?
Personally, I find it easiest to break the business requirements into the smallest unit of work that effectively results in a complete item. Then it becomes pretty simple to break that down across the various code layers as required to ensure an approach that follows clean, SOLID principles. Tests are more easily written for such code.
I don't. Or at least, I strive not to.
I'm saying the same thing, but the flow is test first 🤓