On Automated Test Driven Development
As a software developer with no formal training, I sometimes feel humbled by the more standardised approaches to programming like, for example, Test Driven Development or TDD. But I think that today I finally figured it out.
You see, TDD is supposed to "cover your code" with tests. Once all your tests run without fail, you know that you can focus on other parts of the code, like refactoring, interface or performance improvements or on new features. But what it actually means is a simulation of your client and/or debug person. Once you automatically simulate a client, you can make sure it is satisfied before you move on to the real person. And this is also where the whole thing fails, because it is obviously impossible to simulate a human being without real effort that surpasses the building of the very software you are trying to test. It would be fun to actually do it, then watch the software complain on its own functionality. If any software is going to take over the world, one that emulates an annoying client probably will.
One of the hardest parts to simulate is the work with the interface. No test will ever be able to look disappointed while expressing a lack of enthusiasm on your choice of colors. It is even harder to test web interfaces, although software that can test some of the behaviour of web apps and sites exists, with limited functionality. Also, it is impossible to test for functionality that is not there.
A good use of tests is to address (and in this way document) the bug findings! When you see a bug, you create a test that fails because of it, then you fix the bug. Also, by trying to cover as much of your code with the tests, you get to formalize the access to your code and also are forced to decouple interface from code. No wonder that all the test frameworks are used for Unit Testing. Once you can create a unit or a library of code with no other inputs or outputs than data types, you can test the hell out of it.
But it still leaves the interface out. I have been thinking of ways of describing the test procedure not in code, but in English, something like a unit test for a person rather than a testing framework. This can be further automated, where possible, or just followed by a dedicated tester.
What I would really be interested in would be a general way of creating tests for recurring bugs. A sort of code policy enforcement, if you will, but one that would test for the same bug multiple applications. Can it be done without also formalising the structure of those applications?
You see, TDD is supposed to "cover your code" with tests. Once all your tests run without fail, you know that you can focus on other parts of the code, like refactoring, interface or performance improvements or on new features. But what it actually means is a simulation of your client and/or debug person. Once you automatically simulate a client, you can make sure it is satisfied before you move on to the real person. And this is also where the whole thing fails, because it is obviously impossible to simulate a human being without real effort that surpasses the building of the very software you are trying to test. It would be fun to actually do it, then watch the software complain on its own functionality. If any software is going to take over the world, one that emulates an annoying client probably will.
One of the hardest parts to simulate is the work with the interface. No test will ever be able to look disappointed while expressing a lack of enthusiasm on your choice of colors. It is even harder to test web interfaces, although software that can test some of the behaviour of web apps and sites exists, with limited functionality. Also, it is impossible to test for functionality that is not there.
A good use of tests is to address (and in this way document) the bug findings! When you see a bug, you create a test that fails because of it, then you fix the bug. Also, by trying to cover as much of your code with the tests, you get to formalize the access to your code and also are forced to decouple interface from code. No wonder that all the test frameworks are used for Unit Testing. Once you can create a unit or a library of code with no other inputs or outputs than data types, you can test the hell out of it.
But it still leaves the interface out. I have been thinking of ways of describing the test procedure not in code, but in English, something like a unit test for a person rather than a testing framework. This can be further automated, where possible, or just followed by a dedicated tester.
What I would really be interested in would be a general way of creating tests for recurring bugs. A sort of code policy enforcement, if you will, but one that would test for the same bug multiple applications. Can it be done without also formalising the structure of those applications?
Comments
It's a great question! I'd say abstraction layers, but I'm not really sure how implementation would be. These are new grounds for me, thanks for the info.
Viorel Mocanu