4 ms·

Nothing is farther from me than not automating a highly repetitive process. :) Please don't respond to strawmans, that's not useful for anyone. I'm saying that

Nothing is farther from me than not automating a highly repetitive process. :) Please don't respond to strawmans, that's not useful for anyone. I'm saying that there are things that you can't mock efficiently because the thing you want to mock has a very complex behavior -- this means you can't think of all the possible combinations of how it can deviate from the spec. Let's not forget where the thread started from -- continuous, automated deployment to production. I agree that one should do a lot of automated tests, mock what makes sense to be mocked, etc. However, a fully automated testing means no manual testing, right? That's what is almost impossible in many environments -- and this makes continuous deployment extremely risky. Just to reiterate: I am not against mocking, I am not against automating repetitive processes. I just think that 100% automated testing is not feasible in many cases, and that makes 100% automated continuous deployment infeasible as well.

crdoconnor 12y ago
>I'm saying that there are things that you can't mock efficiently because the thing you want to mock has a very complex behavior -- this means you can't think of all the possible combinations of how it can deviate from the spec. Mocking complex and unreliable behavior by 3rd party systems is part of writing good tests and, ultimately, delivering high quality software. If you can't think of all possible combinations of unpredictable behavior, that's fine. You keep testing until you find as many as you think there are and once you do, you mock it. Once you get to the point where you think you have found all of them, you can release. Continuously. If you never release that point, either you grit your teeth and release anyway, or you never release. If you can do this, you will probably score one over on the competition, because getting to this point is rare and valuable. >However, a fully automated testing means no manual testing, right? Absolutely not. It just means that you've minimized your reliance upon it, and the manual testing you do do does not have to be done at the end of each iteration - it can be done continuously. >That's what is almost impossible in many environments -- and this makes continuous deployment extremely risky. If you are minimally reliant upon manual testing then continuous deployment is not risky. If you are heavily reliant upon manual testing then continuous deployment is risky >Just to reiterate: I am not against mocking, I am not against automating repetitive processes. I just think that 100% automated testing is not feasible in many cases There's a difference between something being hard and something not being feasible. Getting to 100% automated testing is hard, but it is feasible.

crdoconnor 12y ago

>I'm saying that there are things that you can't mock efficiently because the thing you want to mock has a very complex behavior -- this means you can't think of all the possible combinations of how it can deviate from the spec. Mocking complex and unreliable behavior by 3rd party systems is part of writing good tests and, ultimately, delivering high quality software. If you can't think of all possible combinations of unpredictable behavior, that's fine. You keep testing until you find as many as you think there are and once you do, you mock it. Once you get to the point where you think you have found all of them, you can release. Continuously. If you never release that point, either you grit your teeth and release anyway, or you never release. If you can do this, you will probably score one over on the competition, because getting to this point is rare and valuable. >However, a fully automated testing means no manual testing, right? Absolutely not. It just means that you've minimized your reliance upon it, and the manual testing you do do does not have to be done at the end of each iteration - it can be done continuously. >That's what is almost impossible in many environments -- and this makes continuous deployment extremely risky. If you are minimally reliant upon manual testing then continuous deployment is not risky. If you are heavily reliant upon manual testing then continuous deployment is risky >Just to reiterate: I am not against mocking, I am not against automating repetitive processes. I just think that 100% automated testing is not feasible in many cases There's a difference between something being hard and something not being feasible. Getting to 100% automated testing is hard, but it is feasible.