I would be exaggerating if I said that every developer acknowledges the value of testing their code, but it isn't easy to find a developer who will openly advocate never testing code. Usually, that guy is a disgruntled former employee of Google or Microsoft or Amazon and he's really just railing against someone who mentioned his lack of code coverage. Not someone you want to listen to or receive career advice from.
If you're still early in your career and you haven't picked up any books on unit testing, you should. The Art of Unit Testing by Roy Osherove is a good book that is focused on the subject, but Robert "Uncle Bob" Martin's books are a must read though they are generally focused on the entire practice of coding. If you don't have a lot of time to dedicate to reading right now and need a quick shot in the arm to get a handle on what unit testing is, give Osherove a read. I recommend it so much, I won't include a link so you can't accuse me of trying to profit off your education. There. A completely unfunded piece of advice. I'm sure it's worth every penny and whole lot more.
Now, I'm guilty of this myself. I talk about TDD and how awesome it is. I know it's awesome because when I do it, I know I save myself a lot of headache. What does it mean to do TDD? Simple. Write a test that fails (because the code hasn't been written yet), then write the code that's needed to pass the test. This is the Red, Green in Red, Green, Refactor.
Here is where even the best devs, of which I am nowhere close, begin to lose their religion about unit testing and code coverage. The thought is, if I haven't written code, how do I know what the test is going to be? THIS IS THE ERROR! The truth is the opposite and actually a non-issue as I'll explain momentarily. First, it's erroneous to ask this question. The question should go the other way round. You should be asking, How do I know what the code is supposed to do if I haven't written the test? But really, let's address this question as it's often expressed: How do I know what the test is supposed to be?
Actually, I'll ask a question in retort: Do you have Acceptance Criteria? I'll assume you do because if you're writing ANY software without it, you wasting everyone's time. Maybe not right now, but down the road, a lot of wasted money is going to be your fault. So stop writing software without Acceptance Criteria. Now, in the AC, there's always a statement of what's expected. That's the simplest form of non code test you can have. Convert that AC into a unit test. Do that first. Now go write the code that passes that unit test. Congratulations you've passed the acceptance criteria. Only one thing left. I'm sure you're a wonderful coder, but I'll bet some of that code you just wrote has some code smells. Check for multiple responsibilities. If some code is doing more than one thing, that's a good opportunity to refactor. Naming is a good indicator of whether or not something is trying to have more than one responsibility....if you ever get a chance, crack open the DateTime class. Pretty clearly stated in the name this class has two jobs. Don't believe me, fine. Check out Jon Skeet and NodaTime if you time to poke around.
And if you're on a project, your responsibility is senior dev or QA, and the lead engineers begin a project by saying "We don't have time to deal with automating the tests". Raise concerns with your leadership. Don't wait. Because it's almost certain that there's an architect or an engineer in charge of things that doesn't realize that his leaders are opting to cut testing in favor of delivering bug-ridden code fast.
If you're still early in your career and you haven't picked up any books on unit testing, you should. The Art of Unit Testing by Roy Osherove is a good book that is focused on the subject, but Robert "Uncle Bob" Martin's books are a must read though they are generally focused on the entire practice of coding. If you don't have a lot of time to dedicate to reading right now and need a quick shot in the arm to get a handle on what unit testing is, give Osherove a read. I recommend it so much, I won't include a link so you can't accuse me of trying to profit off your education. There. A completely unfunded piece of advice. I'm sure it's worth every penny and whole lot more.
Now, I'm guilty of this myself. I talk about TDD and how awesome it is. I know it's awesome because when I do it, I know I save myself a lot of headache. What does it mean to do TDD? Simple. Write a test that fails (because the code hasn't been written yet), then write the code that's needed to pass the test. This is the Red, Green in Red, Green, Refactor.
Here is where even the best devs, of which I am nowhere close, begin to lose their religion about unit testing and code coverage. The thought is, if I haven't written code, how do I know what the test is going to be? THIS IS THE ERROR! The truth is the opposite and actually a non-issue as I'll explain momentarily. First, it's erroneous to ask this question. The question should go the other way round. You should be asking, How do I know what the code is supposed to do if I haven't written the test? But really, let's address this question as it's often expressed: How do I know what the test is supposed to be?
Actually, I'll ask a question in retort: Do you have Acceptance Criteria? I'll assume you do because if you're writing ANY software without it, you wasting everyone's time. Maybe not right now, but down the road, a lot of wasted money is going to be your fault. So stop writing software without Acceptance Criteria. Now, in the AC, there's always a statement of what's expected. That's the simplest form of non code test you can have. Convert that AC into a unit test. Do that first. Now go write the code that passes that unit test. Congratulations you've passed the acceptance criteria. Only one thing left. I'm sure you're a wonderful coder, but I'll bet some of that code you just wrote has some code smells. Check for multiple responsibilities. If some code is doing more than one thing, that's a good opportunity to refactor. Naming is a good indicator of whether or not something is trying to have more than one responsibility....if you ever get a chance, crack open the DateTime class. Pretty clearly stated in the name this class has two jobs. Don't believe me, fine. Check out Jon Skeet and NodaTime if you time to poke around.
And if you're on a project, your responsibility is senior dev or QA, and the lead engineers begin a project by saying "We don't have time to deal with automating the tests". Raise concerns with your leadership. Don't wait. Because it's almost certain that there's an architect or an engineer in charge of things that doesn't realize that his leaders are opting to cut testing in favor of delivering bug-ridden code fast.
