7 ms·

The real reason I don't write the tests:- Client/ Manager :- When is this going to be ready? Me :- Estimated time for development is n1 days and around n2 day

The real reason I don't write the tests:- Client/ Manager :- When is this going to be ready? Me :- Estimated time for development is n1 days and around n2 days for testing, and depending on the bugs n3 days to fix them. Client/manager :- No no, we don't have time, do it in n1-1 days. And when you ship it with bugs, they have a shocked Pikachu face.

mbrumlow 3y ago
You have to start with test first -- just make them "the task". Don't give estimates separated by test and features. New feature at hand? First thing you code is the scaffolding to call or trigger new feature (this may be trivial on some projects, or impossible on others). So long as you start out that way when asked, how long? The tail end always contains the feature, and they can't say cut it. I worked at a place once where I was setting up a minimal CI/CD pipeline for the project -- I took the first few weeks to do this. In a meeting I was called out by another engineer that had longer tenure at the company. "Are you working on 'devops' stuff because you don't know how to do the primary objective". I responded with a very long triad of why all this other stuff IS the primary objective, and was never questioned again (by that same engineer anyways). All this to say, part of being an engineer is also to educate fellow engineers on ways of doing things better than status quo. It can be hard, and you can put your self at risk. But it's a choice you have to make for your self, the engineer who cuts corners to make mostly arbitrary deadlines, or the one who build robust software. You don't have to go in 100%, but at least have a leaning to one side or the other and make the better choice when it really matters.
- lamontcg 3y ago
  Yeah +1 on not even talking to anyone in management about tests. I've never talked about solving problems like that, always just talked about the time to fix the bug / implement the feature, and test were implicitly part of that. I've also never had a manager start micromanaging me over how many tests I was writing. That's always been my own judgment call to make.
- kderbyma 3y ago
  that assumes you have the leeway to take longer. a lot of issues arise when there is an unforeseen deadline and you get just enough time to get out the code with some bugs and then can add tests and refactor afterwards. usually this happens when a critical component suddenly gets sunset and you need to work in a work around temporarily until you can do it right
  - mbrumlow 3y ago
    I am trying to convey it's not about leeway, it's a yes or no. If you are asked can you get this done in 2 days, and you think "yes, but if I skip test", then your answer is "no, you can't get it done in 2 days". You are simply shipping unfinished work.

mbrumlow 3y ago

You have to start with test first -- just make them "the task". Don't give estimates separated by test and features. New feature at hand? First thing you code is the scaffolding to call or trigger new feature (this may be trivial on some projects, or impossible on others). So long as you start out that way when asked, how long? The tail end always contains the feature, and they can't say cut it. I worked at a place once where I was setting up a minimal CI/CD pipeline for the project -- I took the first few weeks to do this. In a meeting I was called out by another engineer that had longer tenure at the company. "Are you working on 'devops' stuff because you don't know how to do the primary objective". I responded with a very long triad of why all this other stuff IS the primary objective, and was never questioned again (by that same engineer anyways). All this to say, part of being an engineer is also to educate fellow engineers on ways of doing things better than status quo. It can be hard, and you can put your self at risk. But it's a choice you have to make for your self, the engineer who cuts corners to make mostly arbitrary deadlines, or the one who build robust software. You don't have to go in 100%, but at least have a leaning to one side or the other and make the better choice when it really matters.

lamontcg 3y ago
Yeah +1 on not even talking to anyone in management about tests. I've never talked about solving problems like that, always just talked about the time to fix the bug / implement the feature, and test were implicitly part of that. I've also never had a manager start micromanaging me over how many tests I was writing. That's always been my own judgment call to make.
kderbyma 3y ago
that assumes you have the leeway to take longer. a lot of issues arise when there is an unforeseen deadline and you get just enough time to get out the code with some bugs and then can add tests and refactor afterwards. usually this happens when a critical component suddenly gets sunset and you need to work in a work around temporarily until you can do it right
- mbrumlow 3y ago
  I am trying to convey it's not about leeway, it's a yes or no. If you are asked can you get this done in 2 days, and you think "yes, but if I skip test", then your answer is "no, you can't get it done in 2 days". You are simply shipping unfinished work.