4 ms·
> because I was too slow to implement a feature because I was spending extra time writing tests. This. Just yesterday, I was asked by an interviewer at a Star
by justboxing 9y ago
> because I was too slow to implement a feature because I was spending extra time writing tests.
This. Just yesterday, I was asked by an interviewer at a Startup. "How do you test your code? Do you write tests? What's your familiarity with TDD."
My answer: "I prefer to do a test driven approach. However, none of the companies I worked for allocated time for writing tests in the sprint, so I have not been able to actually do this in practice. I usually debug my code and run it through all the happy path and edge cases."
Was bitten once very early in my career just like OP, and decided to only write tests after initial coding, if there was time left. Most (not all) Companies expect you to do TDD, but never allocate time for it in the estimation. So I've made it a point to ask the PM if there was time allowed for writing tests in the estimate, and if they say something like "Oh no we don't have time for that" I don't do it.
- wirrbel 9y agoI couldn't imagine to work without writing tests and I firmly believe it actually makes me quicker than manual coding. Sure, if you aim for 100% code coverage it takes time, but instead of trying out my code a few times, I just write those try-outs as tests and am happy ever after. I don't really mention tests to my management. To me, they are just part of coding. My coworkers don't mind, they are happy when maintaining or changing my code that they have tests for support.
- nkristoffersen 9y agoI just started learning how to write tests for my APIs. Changed my life! Now when I need to make broad changes I can easily tell what needs to be fixed because my tests cover each end point with multiple success and failure cases. Love it.
- Denzel 9y agoThis, exactly this. I've felt the same increase in development velocity; and an equal increase in confidence. I'm able to deliver systems and walk away with 99% confidence that no one is going to come back to me with a problem. And if they do, it's easy enough to write a regression test to prove the problem and then fix it. I've adopted your same approach. I don't mention testing, but I'll be damned if I'll ever write a piece of code without it. The light-bulb moment for me was when I realized that testing happens one way or another. Either you're in the console manually setting up and running everything... or you could just write a program (a test) to do the same thing for you. Once I realized that, I never looked back!
- Denzel 9y agoMaybe you can help me understand something because I hear this a lot. You manually debug and run your code through "the happy path and edge cases", if I'm understanding you correctly... so, does it really take that much longer to write an automated test that does the same thing? What I'm saying is if we accept the company's viewpoint as truth -- I don't -- then you'd just be writing code and handing it over. No testing. No execution. No nothing. But if you have time to manually test the code, then it sounds like you have time to write automated tests. Now, I'm with you, these tests aren't going to be beautiful or well-factored, but they'll be helpful to you, right? That way you don't have to manually test the code over and over again. On the other side of the coin, I've taken on the practice of including time necessary for testing in my estimates (as an employee and contractor). If a manager doesn't want to accept that, then they can fire me, because that manager is fully incompetent -- no ifs ands or buts. As a professional, I need to operate with a test-driven approach. It's the only way to deliver complex systems with confidence. Testing happens one way or another.
- erik_seaberg 9y agoAs the saying goes, you don't have to test all your code, only the code that's supposed to work. I don't give estimates that exclude tests for the same reason I don't give estimates for pseudocode that nearly compiles.