Chris Morgan wrote:
Oh for crying out loud. Go ahead and automate if you know how to. If you or someone else can show me how I am willing to work on it too, I an not opposed to automating all of the testing if that is possible.
In the mean time am against these large patches that are difficult to test because the are so large.
The difficulty isn't that a particular change is large, although yes, if only a few lines of code that were only called from a single location were changed this would make it easy to test. The issue is that the appdb is so large and complex that we aren't using time efficiently by testing manually.
I'm not arguing against automated testing, however not having automated testing is not an excuse for not testing.
Automated testing isn't all that difficult to implement. We can start out with tests for classes, make sure we can create a new user, change the users password and other info and delete the user. Test creating applications and versions. We should even be able to fill in form data and simulate the user entering data and clicking on the submit button.
This is a fine idea...
I already have many of the tests for the user class completed from this last October.
I would like to see this.
Let me finish up closing these sql holes and I'll clean the tests up and submit them as a basis for our automated testing.
I'll repeat I do not want patches going into the live system without being tested. Break them up so that they are easier to test. For the life of me I do not see how on earth you think is this an unreasonable request.
I really do not enjoy arguing with you about this but I feel I am forced too because testing is the only way I can see to ensure that we don't keep busting the AppDB. I have said it before and I will say it again we have lost more data so far through bad patches then through security breaches.
--
Tony Lambregts