When you implement a new feature somewhere, when you change just some bits of your code, when you fix a bug, or you just change a common text in an app… What do you do afterwards? Do you really check the result or do you trust yourself that it works fine 100%. It is an interesting thing to talk about…
I have to be honest and admit that I trusted myself a lot of times in the early days and at least 2 of 10 times I was wrong. If you deal with customers then it’s two times too much. Especially when you have that guy on the phone and you claim that you did change it, but he is browsing the application and does not see any changes. In that case you’re really pissed because you haven’t spent one minute to check the result/consequence of your change.
So that’s why I always suggest to check EVERYTHING that has been changed. You never know what you forget, but when you get sure that you see the change yourself then you’re on the safe side. Here is a list what you could not have thought about:
- you have been working in the wrong file. The file you have been working on was just a backup, in the wrong location, wrong server, etc. Such things happen everyday.
- you forgot to refresh/restart some service, application, etc.
- forgot to publish the file. This is common but i am sure it happens as well. For instance you forgot to upload the file on the server if its a web app.
- forgot to compile. for all out there who need to do this.
- last but not least programing failures which you haven’t thought about (especially when you are changing code of others you should 100% check the effect of the change even if it’s just a typo): you changed the wrong part of the code. Happens usually when there are duplicate pieces of code, which in turn happens because of bad programming style (think of the DRY principle).
Hence it’s highly recommended to check EVERY change. You save yourself and others a lot of troubles and iterations of changing and testing. Personally I think that this is a programmers quality characteristic and that it’s not a tall order to expect a check of the change. In most cases it’s less than a minute. Don’t get lazy …. For sure everybody does, but be aware of all the points I mentioned above.
if you write automatic unit tests first (test driven design) before you do a real implementation and if you use a continous integration systems which makes sure that the chekced in code gets tested as well and if you use some sort of autoamtic deployment system (like capistrano) you shouldn’t have any problems at all and you can really rely on your source code and the work others did.
i must admit that i don’t work this way all the time and in all projects but i try to be behave more the way mentioned above.
Yip , I agree with Fabian. I just can not imagine working on a team project with out unit tests, and following the TDD methodologies. They have saved my skin a few times. The problem though with TDD, is how do you test the presentation layer automatically?