[wp-hackers] Fixing Bugs

[jacobsantos at branson.com]

Well, yeah, also it should be unit tested, along with QA. A few people 
are doing so already and I am one of those people. However, the unit 
tests won't be ready for the 2.3 release, or cover 100% of the 
functions. Some files and functions are unit testable (but are 
acceptance testable and characterization testable), which would add to 
the time needed to test the API functions.

I was able to find and patch a few bugs in a plugins.php alone, which is 
relatively stable. I started unit tests for taxonomy.php, but don't have 
complete coverage and won't probably have it for a few weeks.

Unit tests won't completely stop bugs, unless test are written for the 
bugs after the fact (which is always a good idea, to make sure that the 
bug never shows up again). What I've been trying to do is test the 
expected behavior (characterization tests), instead of the intended 
(what the original developer thought) or morphed behavior (what happens 
when you give the wrong input; garbage in, does garbage come out?).

Unit Tests won't replace manually testing WordPress features, nor would 
acceptance tests when those are complete. Humans have a better odds of 
finding errors where the tests don't and tests have the advantage of 
being able to run so that past bugs don't show up again and make sure 
humans didn't miss out an intended feature.

Some WordPress code would only be tested if someone runs that portion, 
while others require manually entering data from the site.

The best case would to be to also unit test the JavaScript code that 
isn't part of external libraries.

Jacob Santos

Martin at Cleaver.org wrote:
> Indeed, unless a system gets documentation, to explain and put rigour into
> the model of how it should work, bugs will continue to get through the
> cracks.
>
> Martin.
>
> On 8/27/07, jacobsantos at branson.com <jacobsantos at branson.com> wrote:
>   
>> I like this idea, but I think it has more to do with users submitting
>> patches for bugs. Which I think is what the bug hunts are all about,
>> finding and submitting patches.
>>
>> I also think that reasons should be given when closing as invalid or
>> wontfix. It is good bug handling in my opinion and something that won't
>> annoy those who submit bugs. Some bugs marked as won't fix or invalid
>> mean that the bug is external to the application that can't be fixed
>> easily. However, making it clear what the developers intention was would
>> go a long way.
>>
>> There will never be any release in any application where everything
>> works. However, fixing what bugs we have now would be an awesome idea!
>> Documenting the code should go along with this idea.
>>
>> Jacob Santos
>>
>> Geoffrey Sneddon wrote:
>>     
>>> The number in bugs in WP has grown steadily over several years, yet
>>> the number of unfixed ones increasing quicker still. We need a release
>>> that is stable. We need a release where everything _works_. Can we
>>> have one release which includes _nothing_ but bug fixes. There are 409
>>> open bugs according to trac (and I expect there are others marked as
>>> wontfix/invalid without reason). There are some massively annoying
>>> bugs for users, not least things like being unable to use IRIs in
>>> sanitised content (#4570, target 2.4).
>>>
>>>
>>>
>>> - Geoffrey Sneddon
>>>
>>>
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>>>
>>>
>>>       
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>     
>
>
>
>