Re: [AppDB] - protect against sql injection in select, update and delete statements

[Tony Lambregts]

Chris Morgan wrote:
> On Sunday 25 June 2006 10:00 pm, Tony Lambregts wrote:
> > Chris Morgan wrote:
> > > Testing once beats testing over and over and over again IMO.
> > > Thats why you want to make the patches small. Small patches are easy to
> > > review, test and prove the correctness of. Big patches are difficult to
> > > test and one bug rejects the whole thing, so you have to start all over
> > > again.
> > > I suspect that if your testing looks good and mine does as well then we
> > > should be ready to go.
> > > I will NOT be able to test a big patch again for a while, nor am I really
> > > willing to. I took quite a while out of my weekend to do the testing
> > > because I don't want a bad patch going into production again. We have had
> > > enough bad feelings going on over this that it was easier for me to do the
> > > testing then to continue arguing with you. I really have a limit though and
> > > I ask you politely to meet me half way by breaking it up.
> > > I'll fix up moving test results, that should be an easy one, and do
> > > another once over of the patch before comitting it.
> > > I'm pretty confident that it is all set, I've tested submitting notes,
> > > comments, applications, distributions etc here and it looks good.
> > > I do not support that idea. If you break the patch up into smaller chunks
> > > then Those can be tested and hopfully put in.
> >
> > --
> >
> > Tony Lambregts
>
> I'll break up the patch if you'll start submitting patches that implement 
> automated testing.
>
> Otherwise our testing is always going to have poor coverage and is going to be 
> a waste of time.  It might be more difficult to implement automated testing 
> but it will improve the codebase by allowing us to test it quickly and 
> reproducably.
>
> Chris

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.


--

Tony Lambregts

[AppDB] - protect against sql injection in select, update and delete statements

[Chris Morgan]

> 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.

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.

I already have many of the tests for the user class completed from this last 
October.  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.

Chris

[AppDB] - protect against sql injection in select, update and delete statements

[Tony Lambregts]

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